Ok, I have web.config set to Forms authentication. I set path, loginurl and timeout. Set up some roles in asp administration, and some users. In my login page, I have the following as part of the code:
If Membership.ValidateUser(ViewContext.Request.Form("username"), ViewContext.Request.Form("password")) Then
FormsAuthentication.SetAuthCookie(ViewContext.Request.Form("username"), True)
It seems to be working (I tested the return of ValidateUser, it returned true of false when expected), but when I then move to another page in the app some things don't have set value, such as User.Identity, and Roles objects. Could SetAuthCookie by dependant on something of which I am not aware?
I never use the .net built in roles, etc. So i dnt talk from experience here. But a while ago I read a post and IRC they said that the SetAuthCookie doesnt work with roles for some reason. I find that very strange tho. But again, i could have the bull by the horns here.
Just for interest sake, try FormsAuthentication.RedirectFromLoginPage method instead and see if that works
I tried that as well. I'm not sure if this would have an impact, but in this case, there is no html output for this. It's a specialized handler that returns a file to the user. I have to be able to test their access level to return the right file. Anyway, I can post to the handler from an aspx form, and call Membership.ValidateUser just fine. I'm just curious as to why none of the other IPrinciple objects aren't setup. They should be as soon as you make a call to either of the function we already mentioned (SetAuthCookie and RedirectFromLoginPage). If I post to a different aspx page, just to get the auth working, then for some reason, I still don't have access to it in the handler.
EDIT:
Wait, I just had a thought...
You know how an autogenerated page class is a partial that inherits page? Let's assume you just made test.aspx / test.aspx.vb and partial class test is generated. What exactly is that merged with at runtime? The reason I ask is that the class I'm using in this case is a non-partial class that implements IHttpHandler. This might actually make a huge difference. If there's something not getting mixed in that the security system needs, it just may break.
Oh ok. That is ur problem. The handler will not have the those values as it doesnt have the Page class. If you make it an aspx page that does the same thing. You will probably find that it works.
I had the same issue with a flash uploader that was posting to an ashx handler file. To get the user name, i had to make it an aspx page, then it worked no problem.
The handler is outside the page context scope/pipeline.
Hm...I dunno now that I look at things a bit more. If you can, set the below up as a test and see if you get the same results as I do. There should be no difference between using the stock handlers and a custom one, but it seems that something is getting lost along the way. Of course, it could just be me not knowing something vital.
asp.net configuration
enable roles, add a role, enable Internet auth, add a user and add it to the role.
web.config - besides adding assembly, handler and module...
RouteTable.Routes.Add("ResourceStopRoute", New Route("{resource}.axd/{*pathInfo}", New StopRoutingHandler))
RouteTable.Routes.Add("HomePageRoute", New Route("Home/Page", New HomePageRouteHandler))
RouteTable.Routes.Add("UserLoginRoute", New Route("User/Login", New UserLoginRouteHandler))
App_Code/HomePageRouteHandler.vb
PublicClass HomePageRouteHandler : Implements System.Web.Routing.IRouteHandler
PublicFunction GetHttpHandler(ByVal requestContext As RequestContext) As IHttpHandler Implements IRouteHandler.GetHttpHandler
Return BuildManager.CreateInstanceFromVirtualPath("~/App_Views/Default/HomePageView.aspx", GetType(Page))
EndFunction
EndClass
App_Code/UserLoginRouteHandler.vb
PublicClass UserLoginRouteHandler : Implements System.Web.Routing.IRouteHandler
PublicFunction GetHttpHandler(ByVal requestContext As RequestContext) As IHttpHandler Implements IRouteHandler.GetHttpHandler
Return BuildManager.CreateInstanceFromVirtualPath("~/App_Views/Default/UserLoginView.aspx", GetType(Page))
EndFunction
EndClass
- Just make it a new page, place a Login control on it. Save.
Run and test. It seems to validate ok, because it's forwarding to the home page, and not back to the form. But the status controls displays "Login", and the username control is blank.
Maybe if you can see first hand what's going on, you can help. I know there is no real reason to do the above in a real application, though I am now interested in WHY it doesn't work. For all intents this should work the same as having used the default handler to load the page.
Bookmarks