Last post May 11, 2005 03:14 AM by dland
May 05, 2005 02:55 AM|dland|LINK
May 06, 2005 11:13 AM|RBrown|LINK
As you know, authentication happens with every request for a site setup for Forms Auth. Allow me to post something that I write in all my Global.asax files to remind me of why I have this code :)
// The only reason to include code here is to assign a security principle
// that includes roles to the current user following every request. If
// roles are not being used, this code is not necessary. The "normal" code
// in the the Login.aspx merely assigns user roles (if used) to the UserData
// property of the encrypted Authentication Ticket, which is then added
// to the HttpCookie and sent in every following browser request. However,
// because of the stateless nature of web applications, the current users's
// Context does not "automatically" establish a security principle for authorization
// requests (i.e. the ability to use IsInRole("somerole")). As a result, this
// pricipal must be re-established on every subsequent request. The HttpCookie
// with the encrypted UserData property (which srores user roles) contains the
// current user's role information if established during the login procedure and
// this info is maintained on every request for the duration of the user's session.
// So, the code in this procedure merely retrieves the role info from the encrypted
// authentication ticket and re-establishes the security principle for the current
// user, which then enables IsInRole authorization calls.
So, I think what you are asking in 1) is that the first cookie in the Signin routine establishes the encrypted authentication ticket for the user for all future requests. The Auth_Req function manually reestablishes the security principal for role checks...I
know this sounds weird, but it is a necessary evil because of the stateless nature of the web. Not sure about your 2) and 3) though.
My question would have to be why in the hell was this setup to use Windows Authentication :( . I think that was a poor choice and limits the implementation of the app for client intranets, especially if they are on co-lo sites. I'll post a new thread on
this to see if anybody has made the switch and how much time it took. Otherwise I'll do it myself (if the client pays for it of course).
Hope this helped somewhat,
May 07, 2005 04:08 AM|dland|LINK
May 07, 2005 09:29 AM|RBrown|LINK
That is exactly right. I never use GetRedirectUrl or RedirectFromLoginPage as these methods automatically create a NEW authentication ticket and call the SetAuthCookie which effectively wipes out any tickets and roles that you may have already created in your
manually generated HttpCookie. Basically these methods overwrite anything you did manually and are meant to be used be developers who do not wish to have detailed control over the authentication process.
In your estimation, how long did it take you to implement the Time Tracker and do you think that it can be implemented in a 3rd party co-location facility without too much trouble? Still have the issue of Windows Auth vs. Forms though that I need to find
an answer to.
May 11, 2005 03:14 AM|dland|LINK