StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>i need more data on certain pages depending on what the user does. right now i am using sessions but now i want to move everything over into cookies. it's not a lot of data so i figured i could piggyback everything into the auth ticket/cookie</p> </blockquote> <p>@jorsh1 based on your commend to @Portman, Ticket.UserData isn't the place to store changing data. You don't want to recreate the authentication ticket all the time when going from one page to another.</p> <p>Either use Session data with the <em>Session Service</em> or <em>Sql Server</em>. If you don't want the data in session, and the data is small and not sensitive then use a cookie. (*)</p> <p>The MS canonical example with UserData is to store things like a list of Roles so that you can say things like "Do I think this user is an admin" but if it's something like an admin role, you'd probably hit the database to check before you implicitly trust what's in the cookie.</p> <blockquote> <p>string plainTextUserData = fid.Ticket.UserData;</p> </blockquote> <p>This does work inside your app only because Asp.Net has already decrypted the ticket for you. However, if you want to set the data IIRC you need to recreate and reattach the forms authentication cookie. </p> <pre><code>FormsAuthenticationTicket ticket = new FormsAuthenticationTicket( currentTicket.Version + 1, currentUser.UserName, now, now.Add(formsAuthentication.Timeout), false, "new user data string", FormsAuthentication.FormsCookiePath); string hash = FormsAuthentication.Encrypt(ticket); HttpCookie cookie = new HttpCookie( FormsAuthentication.FormsCookieName, hash); Response.Cookies.Add(cookie); </code></pre> <p>Another App can't decode this ticket unless it knows the decryption key or it was brute-forced. If you load-balance the App or use web gardens, <a href="http://msmvps.com/blogs/omar/archive/2006/08/20/forms-authentication-failed-for-the-request-reason-the-ticket-supplied-was-invalid-solution.aspx" rel="noreferrer">you even need to keep the keys in sync.</a></p> <p>* I'm not a proponent of storing things in session. Usually there's another way to persist that data.</p> <hr> <p>[edit] What I use session for:</p> <p>The only thing I often find myself doing is storing a lite version of the users critical data in the session-server based session. We however make it transparently-loaded, and make sure not to duplicate what's in the Ticket. </p> <p>That way we don't expose anything sensitive in cookies, and we don't rely on session. We also set aggressive session reclamation. Combined with the small amount of data being stored in session, sessions don't cause us problems, and as only 1 piece of code knows whats in the session, we could refactor it easily. </p> <p>For anything else, sessions are evil. I prefer to maintain viewstate within a page that needs it, or otherwise just persist the temporary state in the database. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload