Jul 11, 2009 at 2:00 PM
Edited Jul 11, 2009 at 2:06 PM
I am very happy to make the code for FormsAuthentication available.
But there was some other more serious issues with the architecture of the product itself.
These were so serious, that a complete re-write was easier, than adjusting the design to support
FormsAuthetication. This is probably why the product does not support it as an option now.
This is in no way a criticism of the product, simply an observation on the appropriateness of the
product to support an alternative authentication model.
The original design clearly did not, and at the authors own comments, require FormsAuthentication.
It is designed to use the Users Group Membership to determine the scope of access to SlickTicket.
I am Microsoft certified with 8 years c# dotNet experience (from beta) and 30 years programming,
so this conclusion is not due to a lack of experience or skill to make the changes needed.
As a result, we actually ended up extending our own product rather than extend the
brilliant SlickTicket product.
The problem (as we see it) was due to the way that users are grouped by the active directory. So there is nothing in
the database design of SlickTicket, to group the users, so as to determine what they
can, and cannot, get access to.
So, you would need to create a way to create groups for users, then create
a way to issue this group in the authentication cookie.
It also means there is nothing to allow you to administer the grouping either, and members of the group or their permissions.
So you would have to write this too.
All these features are contained withinin the active directory. From within the Active Directory, which users belong to which groups.
The product also uses LINQ to manage the database, which is great for smaller applications, but leaves the business logic embedded
within in the web layer. All beit, seperate classes, but nonetheless, contained within the application.
Not ideal really. We have a corporate policy of separating this type of logic into a discreet and separate layer contained within the database.
We have many thousands of concurrent users, so we need serious scaleability.
I reviewed just about every open source asp.net support ticket application in the market, and SlickTicket is a truely
excellent application. But it is specifically designed for an Active Directory environment, and not a wider audience.
We needed a product where a user could be a member of a group, ie, a customer, and they could raise a support ticket.
Any one of their collegues could login and see any of the tickets in their group. But they clearly could not 'see' the tickets
raised by other customers. So, we have something like 20,000 customers. Each customer could have between 1 and 20 ish
users who all could raise tickets. Even the simple scenario, like 50 customers, each with between 1 and 3 users is not something
you can model within SlickTicket.
So, contact me on firstname.lastname@example.org for the FormsAuthentication code. I am happy to post it here, but I am not sure
where to put it.
And on a final note, thank you to the developer of this application. You should be rewarded for creating a remarkable
support application that organisations could make use of internally. I think you are not far off a superb application that could
be used for the type of thing we need.