Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Feb 01, 2013 01:50 AM by DallasSteve
Jan 31, 2013 11:04 PM|LINK
Based on past experience most of you will want to know why I'm doing this and you will probably tell me it's a bad idea. So I will tell you why up front, and you probably won't be able to change my mind. My website will have no users. It's not e-Commerce,
nor forum, nor blog - just information. Later maybe, but not in the near future. So I don't want to create a membership database. I just want to be able to log myself in to do admin functions on the admin pages. And I want to be able to use the web.config
file to control access to the Admin folder where those pages are stored. I tried passing a username and password to FormsAuthentication.Authenticate which compares them to my user credentials in web.config and it appears to return true. But when I check
HttpContext.Current.User.Identity.Name it is still empty. Cookies are supported (I checked that property). I've written a custom membership role provider so I'm ready to validate my identity but I have no identity. I really want to have an identity. Can
you tell me how to load the Current User Identity?
Jan 31, 2013 11:49 PM|LINK
Yea, sounds like the membership provider is overkill.
As for checking User.Identity.Name or User.Identity.IsAuthenticated, are you calling these right after you call FormsAuthentication.SetAuthCookie? FormsAuthentication.SetAuthCookie issues a cookie so it's not until the next request where the User object
is populated (from the cookie). Also, FormsAuthentication.Authenticate just returns true/false -- it doesn't issue the cookie.
Feb 01, 2013 01:32 AM|LINK
I am calling FormsAuthentication.Authenticate then I keep checking for Current.User.Identity on subsequent page loads. It's not there, so the cookie, I guess, is not getting set. That brings me to your last comment. You said FormsAuthentication.Authenticate
doesn't issue the cookie. Do you know what does? In my mind there is an Identity somewhere being loaded with data about that user, in this case I guess it's only the name and password. Does it only exist in the cookie or is that state being maintained somewhere
else that I don't understand and the page reads that Identity state from that other location on each page request?
Feb 01, 2013 01:44 AM|LINK
FormsAuthentication.Authenticate just checks the username/password against the credentials stored in the .config. You still have to issue the cookie once that API returns true.
Feb 01, 2013 01:48 AM|LINK
I'm trying to work this through and I re-read some membership information on MSDN. I was using the standard ASP.NET Login control, but I was catching the OnLoggingIn event and setting cancel to true. So I thought I will go ahead and call FormsAuthentication.RedirectFromLoginPage(sUserName,
true); which true means create the cookie. But it fails because it's looking for the 'LocalSqlServer' database. That's what I don't want it to do. I don't want to create a database for this. I want it to just use my credentials in the web.config file,
or some other simple storage. Am I on the right track or do I have to set up the database monster just to store my one username and password. I absolutely will not do that in this case. Been there, done that, avoid it whenever possible.
Feb 01, 2013 01:50 AM|LINK
It's working now. I feel so smart. I made one more change: I returned cancel to true. So with cancel to true it doesn't look for the membership database. The FormsAuthentication.RedirectFromLoginPage appears to create the cookie. User.Identity.Name
now has my user name and web.config is allowing me to access the Admin pages.
Thanks for helping.