My site allows anonymous users.
I saw that under heavy load anonymous users get sometimes profile values from other users.
I first delete my cookies and get a valid unique value in the cookie value .ASPXANONYMOUS. After a couple of requests I get a new value for .ASPXANONYMOUS which is already used by another user. I see in my loggs that there are always a couple of users who share the same value in .ASPXANONYMOUS.
I can see in the my logs that 2 or more users realy get the same cookievalue for .ASPXANONYMOUS even if they have different IP.
Here is the htttp traffic. In the second image the changing cookie is shown (You have to display the image full size do be able to read the log):
One of the many requests that work ok:
alt text http://img413.imageshack.us/img413/2711/log1.gif
Then there is this one request that changes the cookie
alt text http://img704.imageshack.us/img704/8175/log2.gif
Then the new cookie is used
alt text http://img704.imageshack.us/img704/3818/log3.gif
Just to be safe I removed dependency injection.
I dont use OutputCaching.
My web.config has this setting for authentication:
<anonymousIdentification enabled="true" cookieless="UseCookies" cookieName=".ASPXANONYMOUS"
cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" />
<authentication mode="Forms">
<forms loginUrl="~/de/Account/Login" />
</authentication>
Does anybody have an idea what else I could log or what I should have a look at?
UPDATE
I saw now that the http-traffic I showed is perfectly valid. A changing value in .ASPXANONYMOUS is something that happens because the cookie gets refreshed. The value contains AnonymousID and a Timestamp.
This does not lead to users having the same value in .ASPXANONYMOUS under normal conditions.
The problem realy is, that whenever the cokies get set from the AnonymousIdentificationModule, then there is a chance that a couple of user get this cookie. Setting a cookie in my application doesnt have this strange sideefect.
I had the same problem and solution was to turn off output caching for the responses where you call SetCookie. Below are several links describing this
Don’t let your cookie being cached by accident!
ASP.NET Session Mix-up using StateServer (SCARY!)
Integrated Pipeline and the kernel-mode cache
Are you declaring any static variables in your code at all? I had this similar issue, and narrowed it down to that; at least for my situation.
Related
I am developing ASP.Net MVC application.
We have used sessionState mode SQLServer and i have set timeout to 20 minutes.
<sessionState mode="SQLServer"
sqlConnectionString="data source=127.0.0.1;user id=sa;password=sa"
cookieless="false"
timeout="2" />
Code is something like this in web config.
I have also set login page.
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="2880" />
</authentication>
Now when session expires i want to navigate user to login page.
I checked many things but i was unable to understand how it exactly works? and how can i navigate user login page on session expire?
It is working in InProc mode. I used it in same way and user is redirected to login on session expire.
But i am unable to accomplish same thing in SQLServer Mode.
I am unable to understand what i am missing?
I checked Session State and also found that Session timeout handled in SQLServer Mode
Edit :-
I want to redirect user to login page whenever another http request is executed for that session.
Ordinarily the browser has no idea what is going on on the server. Unless an HTTP round trip occurs, it will remember the state of the session from when the page was rendered.
In addition, you session cookie is probably HttpOnly, so there is no way for the page to check for the presence of a session cookie.
One way to accomplish what you want is:
Add a hidden iFrame to your page. Set the SRC of the iFrame to a handler in your web site
The handler doesn't have to do much except return a 200 OK, plus a refresh header set to a few seconds, so that the handler gets continually polled.
context.Response.AddHeader("REFRESH", "2");
Add framebreaker code to your login page
if (top.location != location) {
top.location.href = document.location.href ;
}
When a request for the handler occurs with an expired session, it'll get redirected to the login page via forms authentication; when the login page is returned, it'll break your iFrame and redirect the full window to the login page.
Or, you can do what everyone else does, which is wait for the user to request another page.
For me, changing the timeout value in the web.config file to anything didn't take place, and the reason was there were somehow some leftover old records in the ASPStateTempSessions table in ASPState database. I had to empty the table and only then my web.config changes took place. I wasted an hour trying to search for the cause so hope this helps someone.
So, run this:
delete from ASPStateTempSessions
Difference between InProc and SQLServer mode is that SQLServer relies on MSSQL job to remove the session. It actively doesn't prevent you from login again.
See Session State Providers
SqlSessionStateStore doesn't actively monitor the Expires field. Instead, it relies on an external agent to scavenge the database and delete expired sessions—sessions whose Expires field holds a date and time less than the current date and time. The ASPState database includes a SQL Server Agent job that periodically (by default, every 60 seconds) calls the stored procedure DeleteExpiredSessions to remove expired sessions.
I'm experiencing an odd behavior on ASP.NET <sessionState> configuration.
I'm trying to use mode="SQLServer".
When I put cookieless="true" everything works happily as it should be and the ASPStateTempSessions table get filled as expected.
When cookieless="false" ASP.NET simply ignore my configuration and host the sessions in its process (nothing on ASPStateTempSessions).
I have no idea why the cookieless configuration is yielding such unexpected behavior.
Anyone know why this happens or how do I solve it?
By the way here's my configuration:
<sessionState mode="SQLServer" allowCustomSqlDatabase="true" sqlConnectionString="MyConnectionString" />
P.S.:
I've double checked my browser cookies, it's definitely nothing to do with my browser.
I also tried to use a custom implementation just to for the sake of testing.
The exact same behavior happens, only works with cookieless="true".
When cookies are used in the web.config the session will not be created on first use until something is persisted to the session object. This means that the database will not be updated and the cookie will not be written to the server. You can test if this is the case by writing some dummy value back to the Session object and then checking to see if the database record has been created and the cookie written to the browser.
I have seem a few of these asking the same question but none of the solutions have worked for me thus far so I wanted to see if I am doing something wrong. I have a site that I am using asp.net MVC to create, at current I am using forms authentication to prevent anonymous users from browsing the site. That bit of code is as follows.
<authentication mode="Forms" >
<forms loginUrl="~/login" timeout="15"/>
</authentication>
Then I have a login controller that has the user enter their userName and password then creates an authcookie if the information is accurate.
if (password == encryptedPassword)
{
FormsAuthentication.SetAuthCookie("user", true, model.userName);
}
All of this works in Firefox and Chrome and after the user has logged in he is able to browse the site. However in IE it keeps returning to the log in screen because it keeps recognizing the user as an anonymous user. I checked and the Auth cookie is either never created or doesn't persist as soon as you enter the next page. Some of my attempts to fix this involved using cookieless in the web.config. The only one that works was the one that actually puts the cookie in the URI and we can't have that for the site. Then I tried setting ticketCompatibilityMode="Framework40" but there was no luck there either.
I did see a bug with domain names having non-alpha numerica characters. I currently use the IP to access the domain directly, so I don't know if periods run this problem but even my local host suffers from the same issues. Any input would be appreciated.
Parameters should be in the following order.
FormsAuthentication.SetAuthCookie(model.userName, true, ...);
OR
FormsAuthentication.SetAuthCookie(model.userName, true);
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.setauthcookie.aspx
I am pretty sure I do not have a unique problem, but I have searched all over google and this site and I haven't found a solid answer for what I am looking for. So I wanted to explain myself to see if I could get any help on this issue:
We (my co-workers and I) determined that we need have cookie-less Sessions because our users require multiple sessions to get their work done in a more productive fashion.
Example
Bob the user could have initiated a long running process in window A and in order to continue working Bob will open window B which spawns a new session. This is necessary in order to not disturb what is going on in window A. Every time Bob opens a new window, he has to log in again.
The Problem
I am not really sure if this is a real problem or not, hence my reason for asking. The problem I think I have discovered is that each time Bob logs in, the current Forms Authentication Ticket (and Cookie) are over-written. Now I do not understand how this is okay or why the previous Session/Window combo is still valid after Bob logs in a second time. Since the ticket was over-written doesn't that mean the first Session/Window combo should end because the ticket is no longer valid? This is with respect to:
Request.IsAuthenticated //Making sure the supplied ticket is valid
Questions
So since the Forms Authentication Ticket (and Cookie) are being over written, what does this mean?
Should I be concerned that the ticket (and Cookie) are being over written?
During login, should I be intercepting the ticket (if any) and checking for its expiration? If it is not expired should I try to renew the ticket or just make a new one?
FormsAuthentication.RenewTicketIfOld(ticket) //Just an example
If I am using a cookie-less session should I just use cookie-less Forms Authentication too? The point of doing this would be to make each Session/Window 100% independent of each other. No over-writing would occur anymore. Is there a draw back to this? I can't think of any.
PS: I know the cookie is just a container for what ever is being stored in it, like a Key Value pair.
Additonal Info...
Forms Authentication Ticket:
IsPersistent set to true
Ticket Version 2
Forms Cookie:
Key = FormsCookieName (from web.config tag)
Value = Hashed Ticket
Web.Config:
<sessionState
cookieless="true"
mode="SQLServer"
sqlConnectionString="..."
timeout="300"
regenerateExpiredSessionId="true" />
<forms name="FormsCookieName"
path="../"
loginUrl="Login.aspx"
protection="All"
timeout="300"
slidingExpiration="true" >
</forms>
Using ASP.NET 2.0, with forms authentication.
Just for a test, I configured the roles cookie in web.config like this :
<roleManager enabled="true" cacheRolesInCookie="true" cookieName=".ASPXROLES" cookieTimeout="2"></roleManager>
I wanted to see what would happen when the cached role cookie expired.
Using Fiddler, after 2 minutes had elapsed, I could see that the raw value of the role cookie had changed.
I was expecting that on expiry, that ASP.NET would simply re-read the roles information from the database, and repopulate the cookie with the same value. So my question is, why would the raw value of the cookie change after expiry ? The cookie value is not human-readable (base 64 encoded and/or encrypted ?), so I can't tell if the information in it is the same, although the application still seems to work fine.
EDIT :
It looks like each time the roles are encrypted and cached in the cookie, it gets a different raw value.
e.g. if you run the following code :
RolePrincipal rp = (RolePrincipal) User;
string str = rp.ToEncryptedTicket();
Label1.Text = str;
You get a different value each time.
So the behavior seems normal.
Well the aspxroles cookie only pertains to role queries on the user. Unless you're doing things with the roles that would cause it to function differently (web.config auth?) then you're not going to see anything by expiring the cookie.
Can you share your web.config and basic pages that you're using to test this?
Have you tried that particular configuration to see what changes after the expiration?
<location path="img/logo.png">
<system.web>
<authorization>
<deny users="?"/>
<allow roles="CanSeeLogo"/>
</authorization>
</system.web>
</location>
Based on the question edit:
In my web.config under <configuration><system.web> I have this key:
<machineKey decryption="AES" decryptionKey="{64bits random hex}" validation="SHA1" validationKey="{128 bits random hex}"/>
I'm curious if you set that "manually" if you'll have a constantly changing encrypted string. Also, this is set by default in your C:\Windows\Microsoft.Net\Framework\etc folders, but you can redefine it (obviously) in your web.config to override it per application. This also allows you to share the same cookie cross-app within your domain.
Link to generate random hex strings
https://www.grc.com/passwords.htm
concat the first result from two page refreshes for the second one. Removing the web.config key later doesn't impact your app negatively (of course it wouldn't)