Hi there, Thanks for the reply.
I probably knew it wouldn't make much sense! I'm new to membership stuff yeah. Just don't like the way that additional profile info is stored in like 2 or 3 columns by default. I want to be able to knock up some reports and other things that may need user profile info, so I want it stored in a manner that is easily queryable. If I could find a good guide on writing a custom profile provider then I may be able to use this - can anyone suggest one? On 12 May, 10:51, CallMeLaNN <[email protected]> wrote: > I'm not really understood on what you write here. > > What I know is, you are still new in membership, role and profile. > Sorry if I'm wrong. > > using asp.net membership in user login is more secure and easy. > There is a lots of features including password hashing, lock user if > password fail more than certain count, signout user if idle for > certain period, etc > > 1) asp.net will handle the user object. If I'm not forgotten, there is > a way you can state the user stored in session or cookie. You can > access the user object in code. > > 2) not sure what event you mean and what relation to logged in name, > but don't worry about the logged in name. > asp.net will show it as long as user logged in, no bother about screen > refresh or use new instance of IE, close and open IE again, the logged > in name still can shown. > > If you really know the asp.net membership, you will never forget it. > > On May 12, 5:41 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.
