Re: Session state is not available in this context
From: A.M (IHateSpam_at_sapm123.com)
Date: 03/31/04
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Previous message: Shaun McDonnell: "DPAPI, User Store & Web Farm"
- In reply to: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Reply: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 31 Mar 2004 10:12:39 -0500
Thanks Joe for reply.
Now I know I can't use cache to store user's role.
I have my role definition in sql database. I am trying my best to avoid
query database in Application_AuthenticateRequest.
At this point, I am using user data in authentication ticket but i don't
like the fact that user role information is being stored at client's cookie
storage. beside that if client chooses to persist the cookie, then the role
definition might change in time.
I tried to use session object, Nice try but it doen't work becuse i can't
use session object Application_AuthenticateRequest.
Do you have any alternative for querying database and and using user data in
authentication ticket ?
Thanks,
Ali
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:eTHgHztFEHA.3856@TK2MSFTNGP12.phx.gbl...
> The cache is application scope, so you need to share it with all
concurrent
> users. This is generally easy to do with cache keys that include the a
> unique identifier for the user.
>
> The cache can last as long as you want, depending on the expiration info
you
> provide when you put something in the cache.
>
> One thing the cache can't do is out of process or SQL-based state
> persistence. Those features of session state give you the ability to
share
> state between multiple load-balanced servers and survive work process
> restarts since the state is persisted externally.
>
> A lot of the time, the cache will do what you want and is faster, but it
> depends. There are lots of good articles around that discuss the various
> ASP.NET state management options.
>
> Joe K.
>
> "A.M" <IHateSpam@sapm123.com> wrote in message
> news:ubgH2rlFEHA.3132@TK2MSFTNGP12.phx.gbl...
> > Thank you for reply.
> >
> > Is the Cache's scope at application level or session level ? Does it
keep
> > data for all session long? If it is so, generally why would I use
Session
> > object if i have Cache object?
> >
> > Thanks
> > Ali
> >
> > "[MSFT]" <lukezhan@online.microsoft.com> wrote in message
> > news:zuH0$DjFEHA.3568@cpmsftngxa06.phx.gbl...
> > > Hi Ali,
> > >
> > > AuthenticateRequest event is raised right after a user has been
> > > authenticated but still has not been authorized meaning that
aplication
> > has
> > > not decided on the areas that this user can have access to. And this
> > stage,
> > > application hasn't acquired the state also. So there is no session
state
> > at
> > > this point. You can use the Cache object as Joe suggest.
> > >
> > > Regards,
> > >
> > > Luke
> > > Microsoft Online Support
> > >
> > > Get Secure! www.microsoft.com/security
> > > (This posting is provided "AS IS", with no warranties, and confers no
> > > rights.)
> > >
> >
> >
>
>
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Previous message: Shaun McDonnell: "DPAPI, User Store & Web Farm"
- In reply to: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Reply: Joe Kaplan \(MVP - ADSI\): "Re: Session state is not available in this context"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|