This project is read-only.

Forms authentication

Jun 8, 2009 at 11:23 AM

Hi all,


has anyone got this working with forms authentication, we dont have an AD at the moment and I want to run slick ticket!

we just need to run  5 users e.g. sales, accounts etc... we do have c# devs in house as well...


Jun 9, 2009 at 4:17 PM

I have not got it working with Forms, but would be greatly appreciative if someone did.  Keep in mind that this also would require a revam of the permissions system as it currently relies on AD as well, it's not just for login.

On another note, you should be able to run it just fine without AD, you will just lose the permission restrictions.  Just make sure you select 'Everyone' on the install.

Jun 11, 2009 at 7:57 PM

We want to provide a simple web based ticket system for customers to ask a question and we answer it.

When the customer logs on, they should not be able to see anyone elses tickets, and they certainly should not  be able to delete them, or update them.

Is this going to be possible?


Jun 12, 2009 at 6:45 PM

Ok. We have now made it work with FormsAuthentication.

1) I created a signin.aspx form.

2) we already had a database to lookup users. However, you can easily do this by adding the list to the config page.

3) we added a group for each customer.

That was it.

Jun 13, 2009 at 1:46 AM

Ok, finally ripped out all that tedious Active Directory code, and converted it to a real web based customer support system,
rather than an internal issue tracker. AD is a real limiting factor, and makes the app little more than a intranet system
with a web interface.

Jun 13, 2009 at 1:47 AM

By the way, does anyone actually read this stuff...

Jun 13, 2009 at 7:25 AM

Haha, yes, I reada every post :)

Do you have it set up to choose this option, or is it just hard-coded in?

Would you be willing to release  your code so I can integrate it if it alreaday isn't?

Would you like to be a contributor to the project?

I am pretty excited about this bew development, thank you for your time - please share!


Jun 13, 2009 at 7:27 AM

AD is a real limiting factor, and makes the app little more than a intranet system
with a web interface.

That is all it was originally designed for, sorry if I led you to believe otherwise.

Jun 22, 2009 at 11:09 AM

Hi viewpoint,


can you send the new code to naspinski so he can merge it into a new setup, thanks

Jun 22, 2009 at 11:13 AM

Hi viewpoint,


what I tried was to add the users in the web config, and then add departments in the units table and add groups into the dbo.user_groups table but the code complained about the forms element in the config, it would be great to get your ocde into codeplex, we will also look to add code in where needed and share it back.


thanks again.

Jul 10, 2009 at 9:38 PM

Yes, I also read it. And I need to use forms auth/ the standard SQL membership & roles stuff with this. So I'll be trying to repeat what you just did Viewpoint. Any assistance would be appreciated, but I dare say I'll work it out.

Jul 11, 2009 at 6:49 AM

I would love to have the code so I can integrate this into setup and give the user a choice.  No point re-inveting the wheel when you have already written the code :)

Jul 11, 2009 at 3:00 PM
Edited Jul 11, 2009 at 3: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
 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 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 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.

Best Regards







Jul 12, 2009 at 7:01 AM

As I designed Slick-Ticket, I can agree that it was never really meant to be used with Forms authentication.  When I heard you had implemented it, I was very curious as to how that was done since I could think of no easy way to do it.  I am sorry you couldn't re-factor it to work correctly, but I completely understand as permissions are completely tied up in AD.

That you very much for the praise, that is a huge compliment as I have only been at this .net/C# thing since late 2006. 

Is there anywhere you could upload a .zip of your project?  If not, is there any way you could get it to me so I could post it here?

There is always the possibility you could post it as your own project as well.

Again, thank you very much and good luck!

P.S - shameless plug for my new project for simplifying forms/validation/databinding in [url:], [url:].

Jul 22, 2009 at 1:14 PM

hi, what I would suggest is having a switch in the web config to use either forms or AD. For forms just to keep it simple and use roles (mimic groups in AD) and username and password can be stored in web config under the relevant node... (would be cool to add roles structure to web.config or file eg roles.xml...)

we are finally getting AD and we will not have external clients so looks like we will not need forms auth anyway but if you need help with this let me know...