FormsAuthenticationTicket & userdata
-
I have been playing with the code from http://www.codeproject.com/aspnet/formsroleauth.asp and have run into a small problem. Is there a limit or any restrictions on the value of the FormsAuthenticationTicket.UserData value? If I put a simple text string such as "Administrator,Public" into it all is well. If I serialise an object via the SOAP formatters into it I have problems. Everything appears to work, but HttpContext.Current.User = null in Application_AuthenticateRequest. Any ideas? Thanks Stephen.
-
I have been playing with the code from http://www.codeproject.com/aspnet/formsroleauth.asp and have run into a small problem. Is there a limit or any restrictions on the value of the FormsAuthenticationTicket.UserData value? If I put a simple text string such as "Administrator,Public" into it all is well. If I serialise an object via the SOAP formatters into it I have problems. Everything appears to work, but HttpContext.Current.User = null in Application_AuthenticateRequest. Any ideas? Thanks Stephen.
I had a problem too with UserData. Cant remember what, but I binned the idea. Eventually I just added a call SQL to get the data. Also remember UserData will be encrypted along with the ticket (iow longer text), and cookies has a size limit. 2500 bytes I think. A 30ms call to SQL IMO is much better than the extra 1/2 second (modem user say 2500byte cookie) per request that the user has to wait when loading the page. I have eventually decided to only to let the ticket carry the User.Identity.Name and make calls to the database rather. Hope this helps :) WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
-
I had a problem too with UserData. Cant remember what, but I binned the idea. Eventually I just added a call SQL to get the data. Also remember UserData will be encrypted along with the ticket (iow longer text), and cookies has a size limit. 2500 bytes I think. A 30ms call to SQL IMO is much better than the extra 1/2 second (modem user say 2500byte cookie) per request that the user has to wait when loading the page. I have eventually decided to only to let the ticket carry the User.Identity.Name and make calls to the database rather. Hope this helps :) WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
Now you put it that way, it does not sound such a great idea :) I was getting all hung up on the number of hits to the DB every time a page is requested. If I use ASP.NET cache it will not be that bad. It would be really nice if you could invalidate the cache based on a change in the database via a trigger or something :) I will go the route of pulling the role data from the DB/Cache in Application_AuthenticateRequest. It solves another another issue at the same time, about people being added or revoked from roles having to wait for their ticket to expire before being updated. What do you do about authentication of the cookie? Leave it to the framework? How secure is the cookie against replays and modification? If someone snaffled the cookie off the wire, can it be used from another machine? Suppose the most secure method is to use SSL and never persist the cookie? Thanks Stephen.
-
Now you put it that way, it does not sound such a great idea :) I was getting all hung up on the number of hits to the DB every time a page is requested. If I use ASP.NET cache it will not be that bad. It would be really nice if you could invalidate the cache based on a change in the database via a trigger or something :) I will go the route of pulling the role data from the DB/Cache in Application_AuthenticateRequest. It solves another another issue at the same time, about people being added or revoked from roles having to wait for their ticket to expire before being updated. What do you do about authentication of the cookie? Leave it to the framework? How secure is the cookie against replays and modification? If someone snaffled the cookie off the wire, can it be used from another machine? Suppose the most secure method is to use SSL and never persist the cookie? Thanks Stephen.
stephen woolhead wrote: I will go the route of pulling the role data from the DB/Cache in Application_AuthenticateRequest. It solves another another issue at the same time, about people being added or revoked from roles having to wait for their ticket to expire before being updated. Filter it a bit. Here's what I basically do:
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
if (HttpContext.Current.User != null)
{
if (HttpContext.Current.User.Identity.IsAuthenticated)
{
if (HttpContext.Current.User.Identity is FormsIdentity)
{
if (HttpContext.Current.User.Identity.Name != "Anonymous")
{
string role = // DO SQL STUFF HERE
HttpContext.Current.User
= new GenericPrincipal(
HttpContext.Current.User.Identity , role.Split(','));
reader.Close();
}
else
{
HttpContext.Current.User =
new GenericPrincipal(HttpContext.Current.User.Identity, "Anon".Split(','));
}
}
}
}
}This way you can leave all the auth work to .NET, eg, SignOut() & RedirectFromLoginPage() really works. stephen woolhead wrote: How secure is the cookie against replays and modification? If someone snaffled the cookie off the wire, can it be used from another machine? The only data I have in the cookie is the User.Identity.Name. And that gets ecrypted. stephen woolhead wrote: Suppose the most secure method is to use SSL and never persist the cookie? Perhaps even leave the cookie and only use SessionState to hold some user details. You can of course add SessionData on Session start to cut down on calls to the database. WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
-
I had a problem too with UserData. Cant remember what, but I binned the idea. Eventually I just added a call SQL to get the data. Also remember UserData will be encrypted along with the ticket (iow longer text), and cookies has a size limit. 2500 bytes I think. A 30ms call to SQL IMO is much better than the extra 1/2 second (modem user say 2500byte cookie) per request that the user has to wait when loading the page. I have eventually decided to only to let the ticket carry the User.Identity.Name and make calls to the database rather. Hope this helps :) WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
I did the same, but I used a session to carry all the other data associated with the user. -Steven
By reading this message you are held fully responsible for any of the mispelln's or grammer, issues, found on, codeproject.com.
For those who were wondering, actual (Linux) Penguins were harmed in creating this message.
Visit Ltpb.8m.com
404Browser (Efficient, Fast, Secure Web Browser): 404Browser.com -
I did the same, but I used a session to carry all the other data associated with the user. -Steven
By reading this message you are held fully responsible for any of the mispelln's or grammer, issues, found on, codeproject.com.
For those who were wondering, actual (Linux) Penguins were harmed in creating this message.
Visit Ltpb.8m.com
404Browser (Efficient, Fast, Secure Web Browser): 404Browser.comASP.NET seems to have an option saving session state in a SQL db instead of its memory. Depending on the scalability and usage the choice should be made. My opinion is to use SQL as after the inittial query (asuming it stays the same) the query will be cached and consequent lookups will be very quick (10 ms). :) WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.