Re: lack of understanding of principals, identities, and context

From: Bryan Ax (bax_at_kleinbuendel.com)
Date: 08/21/03 

Date: 21 Aug 2003 07:39:02 -0700

>From a performance perspective, which is going to be more efficient -
custom session variables, or recreating an authentication ticket on
every Application_AuthenticateRequest?

There is no other way to maintain a principal and identity without
doing it every request, huh? Bummer.

"Teemu Keiski" <joteke@NOSPAMaspalliance.com> wrote in message news:<#jqC#GyZDHA.1280@tk2msftngp13.phx.gbl>...
> 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.1280@tk2msftngp13.phx.gbl...
> > > 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
> >
> >

Relevant Pages

  • RE: Membership Provider Woes
    ... in forms authentication context. ... how do I actually store the custom information? ... limited by the natural of cookie. ... Doens't the membership provider set a forms auth cookie for me ...
    (microsoft.public.dotnet.framework.aspnet)
  • Runtime error when customErrors are Off
    ... "On" Always display custom messages. ... This section sets the authentication policies of the application. ... Application-level tracing enables trace log output for every page ... <!-- SESSION STATE SETTINGS ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: authentication cookie vs session cookie
    ... level of using authentication cookies on the client machines. ... authentication cookie on a manager's machine is stolen and used on a client ... > session variables as it relies on the session cookie that ASP.NET sends to ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • RE: authentication cookie vs session cookie
    ... doing 'cookie' authentication (effectively what you are doing when you use ... session variables as it relies on the session cookie that ASP.NET sends to ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • RE: Membership Provider Woes
    ... cookie regardless of whether the user's authentication failed or not. ... how do I actually store the custom information? ... Doens't the membership provider set a forms auth cookie for me ...
    (microsoft.public.dotnet.framework.aspnet)
Loading