Re: lack of understanding of principals, identities, and context
From: Teemu Keiski (joteke_at_NOSPAMaspalliance.com)
Date: Wed, 20 Aug 2003 16:49:48 +0300
It really concerns things when authenticating and/or authorizing are hard
customized and it isn't just Forms Authentication specific. In simple case I
don't see anything wrong with simple session solution but framework support
is one main thing why I'd avoid it.
Other thing when it is used would be when you use role-based authentication.
In that case you could let Forms Authentication to handle the authenticating
and store roles into the login cookie (UserData property of
FormsAuthenticationTicket). Then on Application_Authenticaterequest it is
checked if Request.IsAuthenticated=true (login cookie exists in case Forms
auth) and then roles read from cookie and again custom IPrincipal populated
with information regarding roles.
In case when cookies are not allowed, you still can use Forms Authentication
(I think I have explained it to you earlier). In that case the
FormsAuthenticationTicket is persisted in the Querystring, but the drawback
was with keeping this on every page so that login information is persisted
when user navigates on the site. But if you want to avoid this drawback,
getting to use cookieless sessions is one solution and that leads to the
solution you discussed about.
-- Teemu Keiski MCP,Designer/Developer Mansoft tietotekniikka Oy http://www.mansoft.fi AspInsiders Member, www.aspinsiders.com ASP.NET Forums Moderator, www.asp.net AspAlliance Columnist, www.aspalliance.com "Lauchlan M" <LMackinnon@Hotmail.com> kirjoitti viestissä news:%23asS0TwZDHA.email@example.com... > > HttpContext is request specific (recreated for every request) and > therefore > > you'd need to set the user on every request that means creating instance > of > > FiveADayPrincipal and assigning it to the Context.User. > > > > Therefore there exists methods in Global.asax as > > Application_AuthenticateRequest as they are called on every request and > can > > be used to set the Principal. > > So, if you are not using cookies, what is the best way to maintain state > across a session? Do you set a session variable, say UserID, when the user > logs in, and get the user information from this in the Global.asax > Application_AuthenticateRequest each time to repopulate the context object? > > If you've gone this far with rolling your own solution, why bother with > setting the MS context authentication stuff on each Global.asax > Application_AuthenticateRequest, but instead just check the filepath using > HttpContext.Current.Server.MapPath() (or whatever else you need to configure > you authentication framework) and set roles and permissions accordingly in > your own framework (eg session variables)? > > It would not be too heavy (only involving two or three session variables, eg > userID, role, and permissions). > > What would be the pros and cons of this approach? > > MS have not made their forms authentication framework intuitive at all IMO. > > Lauchlan M > >