<matt@mailinator.com> wrote in message
news:1151530520.896218.217670@j72g2000cwa.googlegroups.com...
> hello,
>
> im familar w/ *forms* based authentication, and i have coded several
> public-facing web sites that authenticate w/ a forms-based login page;
> then get back an array of user roles, and from global.asax.cs's
> Application_AuthenticateRequest() assign the roles to the
> Security.Principal user.
>
> now i am working on a *windows* based authentication webapp for an
> intranet. all users use the windows network to login, and then they
> bring up my webapp.
>
> ive set up IIS & web.config, so i have no trouble grabbing their
> User.Identity.Name (their windows login). cool. and since i am able to
> use global.asax.cs's Application_AuthenticateRequest() i can retrieve
> their db-stored roles assign it to the Security.Principal user. cool.
>
>
> the problem? "Application_AuthenticateRequest()" gets called on every
> single page request, which means a hit to the database to get the
> user's roles every single pageload. is this normal? (i cant remember if
> thats how my prior forms-based webapps worked, too..) if it is normal,
> what is the best practice -- deal w/ it? use the Session to cache the
> user's roles?
>
>
> here is my code:
>
> protected void Application_AuthenticateRequest(Object sender,
> EventArgs e)
> {
> if (Request.IsAuthenticated)
> {
> System.Web.HttpContext context = System.Web.HttpContext.Current;
>
> string userName = context.User.Identity.Name; //format:
> DOMAIN\user.name
>
> //populate my app-user (gets roles from database)
> AppUser myUser = AppUser(userName);
>
> //assign its roles to security model
> context.User = new
> System.Security.Principal.GenericPrincipal(User.Identity,
> myUser.Roles);
> }
> }
>
>
> thanks!
> matt
>

Joe Kaplan (MVP - ADSI) wrote:
> Yes, that is normal. To avoid a database hit, you can use the cache or use
> session state or perhaps a cookie (if it is properly MACed or encrypted to
> prevent tampering).

Joe Kaplan (MVP - ADSI) wrote:
> To avoid a database hit, you can use the cache or use
> session state or perhaps a cookie

wrote in message news:4580be631a1a338c869c44c7fc4c2@news.microsoft.com...
> Hi,
> session is not available in Post/AuthenticateRequest - i would use the
> cache or a cookie
>
> cache has the advantage of being self managed and server only
> if cookie i would use the userData field of the FormsAuth ticket - this
> gives you encryption and integrity protection + renewal for free
>
> In both cases (a little easier with the cache) - you should periodically
> check if the user is still valid and the group memberships are still OK -
> otherwise you end up with stale information - especially if sliding
> expiration is used.
>
> ---------------------------------------
> Dominick Baier - DevelopMentor
> http://www.leastprivilege.com
>
>> Joe Kaplan (MVP - ADSI) wrote:
>>
>>> To avoid a database hit, you can use the cache or use session state
>>> or perhaps a cookie
>>>
>> actually, i think the options may be limited to the Cache or a cookie.
>> it appears the Session object doesnt yet exist "Session_Start()" is
>> executed *after* "Application_AuthenticateRequest()".
>>
>> i had thought perhap i could just check for Session being null, if so
>> grab from db, and that after page hit-one Session should then exist.
>> but...it doesnt. dah!
>>
>> so it looks like Cache or cookie are the only options. if i did Cache
>> i supposed id use a unique key based off the userID, w/ a short
>> time-to-live.
>>
>> matt
>>
>
>

<matt@mailinator.com> wrote in message
news:1151593316.190807.24320@i40g2000cwc.googlegroups.com...
>
> Joe Kaplan (MVP - ADSI) wrote:
>> Yes, that is normal. To avoid a database hit, you can use the cache or
>> use
>> session state or perhaps a cookie (if it is properly MACed or encrypted
>> to
>> prevent tampering).
>
> thanks, joe. ill likely store them in the session or a cookie. i did a
> quick google on MAC -- is this message authority checking? an article
> (non-.NET) mentioned an MD5 algorythm.. know of any nifty .NET code for
> this?
>
>
> thanks!
> matt
>

> Joe Kaplan (MVP - ADSI) wrote:
>
>> To avoid a database hit, you can use the cache or use session state
>> or perhaps a cookie
>>
> actually, i think the options may be limited to the Cache or a cookie.
> it appears the Session object doesnt yet exist "Session_Start()" is
> executed *after* "Application_AuthenticateRequest()".
>
> i had thought perhap i could just check for Session being null, if so
> grab from db, and that after page hit-one Session should then exist.
> but...it doesnt. dah!
>
> so it looks like Cache or cookie are the only options. if i did Cache
> i supposed id use a unique key based off the userID, w/ a short
> time-to-live.
>
> matt
>

Joe Kaplan (MVP - ADSI) wrote:
> I agree with D. You are really implementing a performance optimization
> here, so cache is the most appropriate storage to use.

> Joe Kaplan (MVP - ADSI) wrote:
>
>> I agree with D. You are really implementing a performance
>> optimization here, so cache is the most appropriate storage to use.
>>
> cache it is. i wrote it yesterday, w/ a short sliding expiration -- 5
> minutes. long enough to spare my db from repeated hits from every
> uses's page request, short enough that no user will carry stall roles
> for very long.
>
> thanks guys!
> matt
> http://www.sushi-review.com
> http://www.semi-suave.com

Dominick wrote:
> i wouldn't use sliding expiration - rather choose a longer timeout and no
> sliding exp. - this will guarantee you get fresh info after the timout occured.
> Otherwise you could keep possible old info alive forever by repeatedly sending
> request to the application.