1) I would suggest you to create two separate tables - one for user info and other for the all possible roles. 2) You can maintain the user info in session. 3) And you can create a security class that will be called\implemented in every page or probably master page, that will implement the role access security as per your choice. 4) in case you host it in IIS, you can still set the integrated windows authentication, which is the easiest possible way to authenticate the users.
hope this helps. On Tue, May 12, 2009 at 3:11 AM, Michael_Burgess <[email protected]> wrote: > > I've been looking at all the built-in asp.net membership, role and > profile stuff and although it's easy to implement something, I don't > like the way it's persisted and I can't find any good guides on > writing custom implementations either. > > I could easily create my own login controls, hash passwords, structure > tables exactly how I want, create my own user types etc, but I've just > got a couple of things not sure how to do if I take this approach: > > If I create a login control, user clicks login, in the event handler I > hash their password, call the BL / DL and compare the value - and > either log the user in or reject............ > > That's fine, but if I create a login view type control, the page load > for that will come before the event handler that tries to log my user > in. > > so 1) When I've authenticated a user, where shall I store the user > object I create? Shall I just put it in Session, or shall I create a > cookie first, and then session if that fails? Or should I put it in > the httpcontext user property? > 2) How will I manage the ordering of events, such that when a user > logs, my login view shows the logged in name etc as the screen > refreshes? > > If anything's not clear, please let me know. > > Cheers.
