Why do we need more code in Application_Aut henticateReques t()?

[Andrew]

Hello, friends,

I am implementing a role based authentication (Forms authentication) for our
web app using .net 1.1. I read the paper:
http://msdn.microsoft.com/library/de...SecNetHT04.asp

However, what I could not understand was: After adding a new cookie with
user's roles,

string encryptedTicket = FormsAuthentica tion.Encrypt(au thTicketWithRol eInfo);
HttpCookie authCookie =
new HttpCookie(Form sAuthentication .FormsCookieNam e,
encryptedTicket );
Response.Cookie s.Add(authCooki e);
Response.Redire ct( FormsAuthentica tion.GetRedirec tUrl(
txtUserName.Tex t,
false ));

why one still should "Construct GenericPrincipa l and FormsIdentity Objects"
in Application_Aut henticateReques t(), like the follows?

authTicket = FormsAuthentica tion.Decrypt(au thCookie.Value) ;
string[] roles = authTicket.User Data.Split(new char[]{'|'});
FormsIdentity id = new FormsIdentity( authTicket );
GenericPrincipa l principal = new GenericPrincipa l(id, roles);
Context.User = principal;

I thought Response.Cookie s.Add(authCooki e) already included all info for IIS
to check. Can we skip the above source code in
Application_Aut henticateReques t()? Why?

Thanks a lot for your help.

[Darrin]

I'm not completely sure what your overall intentions are with the forms
authentication, but I would use the second part to load named roles
into the genericPrincipa l object so that my forms authentication would
support different roles having access to different directories. That
way I can specify role access to directories and files (compiled pages)
in the web.config file instead manually coding the access. It also
assigns your current context user to that ticket and roles in case you
wanted to access who you are dealing with from code somewhere.

-Darrin