Im working on a web project in ASP .NET MVC 2.
In this project we store some info inside an ecripted cookie (the ASPXAUTH cookie) to avoid the need to query the db for every request.
The thing is the code for this part has suddenly stopped working.
I reviewed the changes made to the code on the source control server for anything that could be causing it, I found nothing. I even reverted to a known working copy (working on some other persons PC, same code, etc) but after debugging, it seems the .ASPXAUTH cookie is not getting saved anymore. Instead the ASP.NET_SessionId cookie is being set... (wich before wasn't)
I changed the web.config file to turn off the sessionState. This eliminated the ASP.NET_SessionId cookie from being set, but it is still not saving the auth cookie.
Ive recently installed some Microsoft Windows XP Updates, but the other person (whos PC runs the application just fine) also did.
After googling, some info i found pointed out to a problem with the expiration date of the cookie. Ether cus the pc didnt have the right time/date (this was not the case) and others cus of the cookie expiration date being wrongly set. (I checked and it is being set correctly)...
The problem persists with other browsers besides the one im using (Chrome) i tried it with IE6.
Any ideas on why this is happening?
Ill continue to post any helpful information i can find.
Thanks in advance.
This could be that your cookie grew too big. I ran into the same issue.
If your cookie becomes too big, it just won't work, depending on the browser of course
MSDN
cookies are usually limited to 4096 bytes and you can't store more than 20 cookies per site. By using a single cookie with subkeys, you use fewer of those 20 cookies that your site is allotted. In addition, a single cookie takes up about 50 characters for overhead (expiration information, and so on), plus the length of the value that you store in it, all of which counts toward the 4096-byte limit. If you store five subkeys instead of five separate cookies, you save the overhead of the separate cookies and can save around 200 bytes.
What is the maximum size of a web browser's cookie's key?
what happens when cookies file exceeds maximum size?
An easy way to check your cookies size is to debug and run the following code
int cookieSize = System.Text.UTF8Encoding.UTF8.GetByteCount(faCookie.Values.ToString());
If this is over the limit then you will be encountering issues.
In my case after certain amount of head banging against a wall I noticed in my working projects cookie was set using
FormsAuthentication.SetAuthCookie(user.token, false);
in contrast in my not working projects the cookie was being set manually:
var coockie = FormsAuthentication.GetAuthCookie(user.token, false);
coockie.Expires = DateTime.Now.AddDays(7);
Response.Cookies.Add(coockie);
This happened in one of my shared hostings after some change was made by hosting provider which I could not figure out or find out through support dep. local host or other shared hostings or vps worked just fine with the first approuch
Related
Well, I finally had to create an account here. Been using this for years and have often found my answer here, but not this time.
Well, I actually have found a lot of people with similar problems, but none of their solutions have helped me.
I have started on a new MVC3 project, so it's quite simple so far. I've made a handful before, so I kinda know what I'm doing (but not quite, obviously, why else be here ;-)
My problem is apparently a fairly common one: A request starts a new Session, even though the user already has one.
The most frustrating part of this is, it works perfectly on my hosted service, but is broken on localhost.
I have done a number of things to solve this:
There is no underscore in my computer's name.
The Session contains custom data (the error only occurs after user has logged in).
I have added the following to web.config (hmpf, guess you'll have to assume the gt / lt chars):
httpProtocol
customHeaders
clear /
add name="Access-Control-Allow-Origin" value="*" /
/customHeaders
/httpProtocol
and this too:
modules runAllManagedModulesForAllRequests="false"/
With InProc sessionstate, I have tried with 'cookieless' both true and false.
My hosts file contains nothing about localhost.
hm. Looking at this list I'm sure I've left some out. Some on purpose too, as they were hopeless (yes, even more than the above), and born from desperation.
As mentioned this is particularly unnerving as it works on my host - could there be some configuration settings I need to tweak on the dev server (VS2010)?
I've been working from the premise that the issue is due to cross-domain security (it thinks I'm coming from another domain).
The fail happens on this request:
url: 'http://localhost:50396/moody/changeBuilding/' + elem.selectedIndex,
It's part of the options array I use with the jQuery.ajax function.
I change the domain when uploading to the host, but only the part localhost:port, everything else in the application is identical.
I've been banging my head against this for 2 days now, and will miss my exam :-(
I'm determined to bury this 6 feet under, though.
I would be very grateful for any and all suggestions!
I change the domain when uploading to the host, but only the part localhost:port, everything else in the application is identical.
Reading the above, I image the session cookie isn't being sent because you're changing domains.
Let's sit back and think about how sessions work. Basically ASP.NET contains a collection of sessions and their data. When each request comes in, ASP.NET must map that request to an existing session OR create a new session for them.
So how does ASP.NET know what session belonged to each incoming request? Or know that it needs to create a new request? The only way to know this is if the request contained some information, a 'key', which told ASP.NET what session to give the request... or in the absence of this 'key', create a new session.
How does the request send this 'key'? Through cookies.
So therefore, if you change the domain, the cookies isn't going to be sent... so therefore, ASP.NET will create a new session for the request.
Have you tried using something like fiddler to make sure that the session cookie is being sent in the AJAX request. It should be sent if the domain is the same but it's work checking.
Edit: This SO post on changing ports is worth reading too.
Edit: Given the new information in Charlino's comments (and the sterling detective work carried out therein) if the problem is only on your local dev machine then the easiest way to work around your localhost/127.0.0.1 issue is by manually changing the browser url from 127.0.0.1:50396 to localhost:50396, logging in again to get the new cookie, then you are good to go.
We just upgraded to IIS7 and have had intermittent issues with SESSION variables. In a nutshell a very low percentage of users are getting new SESSION IDs with each page request. Clearing cookies has solved this problem for just about every use I've come across.
My question is... Is there a way to programmatically do this? It's been a lower percentage of calls of people unable to login/can't get a certain application to work, so it's not a HUGE deal, but we are having to walk people through the process of clearing cookies all day. I haven't read of, nor seen a way to force users to clear cookies.
Most other questions on here are uses having this issue everywhere, as if there is a programmatic error. Our applications work fine, it's just a small percentage of users who used our applications on our old server can't get new session cookies from the new server.
We were running IIS6/CF9 and we upgraded to IIS7/CF10. This problem is cross browser. We have seen it turn up in IE, FF, and Chrome.
--EDIT--
If a user clears cookies and goes to domian.com and then to sub.domain.com, the domain.com cookie takes precedent and the browser I guess never returns the sub.domain.com cookie it gets from the sub.domain.com server. Turning on J2EE cookies on sub.domain.com fixes the issue, I guess, but the clients still run around with a cookie from domain.com. domain cookies is whatever is set by default... i.e. we don't set it to anything in app.cfc. I have no idea how it is set on domain.com.
In Application.cfc do you have domain cookies set to true?
Sounds like it could be related to the session fixation Hotfix Adobe introduced in February last year. Was your CF9 server fully patched?
In short, CF now issues new CFID/TOKEN values on every session and won't use existing cookie values (to prevent session hijacking). Make sure your app is writing these new values to cookies and not allowing existing cookie values to be used.
Here's a detailed explanation As pointed out in the comments on that post, using J2EE sessions is indeed one way of solving the problem.
We have an asp.net 3.5 web app that we must start load testing with LoadRunner
What we have found is that if you open several browsers (ie8) they share the same session id, so making a change in one window impacts the other windows (not just our app, others app also).
Now, LoadRunner can simulate a number of users per pc, and so we are finding its getting messed up since its all sharing the same session.
Any ideas on what is the best method to prevent this (we don't want to go with cookieless sessions).
How would you ensure each browser window is treated as a unique session?
This is a 'Feature' of IE8 :-S.
You can however start IE in a "start with new session" mode though. use:
iexplore.exe -nomerge
Not to sure how this would be applied to LoadRuner though (Never worked with it)
session/state is unique to a single user, but not across users. You will need to correlate both session and state data across your scripts and then you should be able to execute mutiple users on a single load generator without issue
Whether a new browser session is opened is purely a client side issue. The server does not know or care that a different browser session has been instantiated and is only responding to a valid request as indicated by session token, security token, state token, etc...
While replaying scripts in loadrunner, it doesnt invoke the IE and it wont have impact of the tabs.
Use the setting Check for newer versions of the stored pages every visit will help on this issue.
Also you can put clear cache and cookies before each iteration.so that each time new sessions will be created.
1st post on stackoverflow, hope to have great feedback :)
I'm currently trying to load balance our web site. We have set up a 2 cluster NLB on windows server 2003 with IIS 6.
While testing the setup, I found that sometimes, our session is lost. A day and a half later, here's the result:
Yes, our machine.config both have the same encryption/decryption key.
Yes, the id in iis metabase.xml are the same for both machine. Actually, the entire file are the same, except for "AdminACL".
Both web application are set with "StateServer" and both pointing at the same machine.
From that point, searching on google gives less information and possible solutions.
From what I know, there's no particular pattern that cause this problem. It just happen once in a while.
While trying to find the problem, I've seen that a request sent the asp session id cookie to the server, but the server didn't map it to the user session.
So the request number x was sent from the client, with the cookie, session was mapped, and everything went smoothly.
The request number x+1 was sent from the client, with the cookie, but session was not found.
Both request were made on the same machine in the NLB.
Here's a snippet of the asp trace.axd:
1st request:
Request Details
Session Id: j2ffvy45updpc52uhw1mbg55 Request Type: GET
Time of Request: 11/26/2008 2:58:06 PM Status Code: 200
Request Encoding: Unicode (UTF-8) Response Encoding: Unicode (UTF-8)
Request Cookies Collection
Name Value Size
ASP.NET_SessionId j2ffvy45updpc52uhw1mbg55 42
AID 22 9
Response Cookies Collection
Name Value Size
Headers Collection
Name Value
Cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55; AID=22
2nd Request:
Request Details
Session Id: Request Type: POST
Time of Request: 11/26/2008 2:58:08 PM Status Code:
Request Encoding: Unicode (UTF-8) Response Encoding:
Request Cookies Collection
Name Value Size
Response Cookies Collection
Name Value Size
Headers Collection
Name Value
Cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55; AID=22
As you can see in the 2nd request, the cookie is sent from the client, but asp seems to never add the cookies in it's "Request Cookies Collection". I think that's why it doesn't find the session.
So why the cookie is not mapped to the session? Is that the problem? Is the problem elsewhere?
Feel free to ask any clarifications.
Thank you all for your feedback.
JF
I finally found the answer to my problem. It's origin are within the application code (like 99% of a programmer's 3rd party tools 'bugs'). I decided to post it anyway in case someone is in a similar scenario.
This code was part of WebServiceRequester class. The web service requester class was instanciated when session was created and it is saved in session. During creation, we initalizate the member 'm_webServiceURL', and this member is saved in session after. At which value was this member initialize was depending on a setting on the local machine.
The important part is the following:
WebServiceRequester class contains a WebService objects.
WebService objects can't be saved in session, they are not serializable in asp. The property had the [NonSerialized] attribute on it. So everytime we accessed the 'WebService' property of the object for the first during a page life cycle, we had to create a new one, and assigning ot it the url 'm_webServiceURL' which was saved in session.
So you see, new webservice object, on possibly a different machine, meaning a different setting on each machine.
so here's what happened:
box 29 was set to access Web Service at localhost
box 30 was set to access Web Service as 192.168.253.29.
Technically, they are both set on the same machine. But here's a scenario:
login on box 29. m_webServiceURL is set to localhost in session.
[some request on box 29 here]
NLB balancing bring us on box 30.
box 30 loads it's session, create a new webservice obect with localhost as the web service address.
box 30 made the request to the wrong web service leading to a Session Expired exception.
One of the problem during the debug, was that the local communication were not recorded with the network monitor.
What lead me on the trace, was that we never had an exception logged on the box 29 log trace, as it should have.
Thanks for you suggestions everyone, it was really appreciated.
Have a good day.
JF
Not strictly an answer to your question, but have you tried it using a sql server based session store? (Search on MSDN for the permanent script rather than the temp script that's provided with asp.net)
I've heard "bad things" about the executable session service, and consequently have not used it. Never had any problems web farming with the sql server based solution though.
Sorry it's not strictly an answer to your problem, but it should either (a) fix it, or (b) narrow it down significantly.
Well, if you're using visual studio, you could at least test it with the MSDE (the cut down version of SQL Server that comes with Visual Studio)...
It might help rule out state server problems...
Using the database approach has its own issues. I think you should be able to use your preferred approach.
Perhaps this session troubleshooting article would help?
Or "Troubleshooting Session Related Issues in ASP.NET"
Or "Troubleshooting Expired ASP.NET Session State and Your Options"
I'll be lame and re-iterate the proposal of MS SQL Server. Install SQL Server Express which is completeley free including for commercial use and it has only these 3 drawbacks which shouldn't be a problem for you in this stage :
Max 4GB size database
Max 1 CPU Core used
Max 1GB RAM used
A few points to take into consideration:
What's the load on your website? State Server has the tendency to crash when facing a large number of concurrent hits. We're only using it in scenarios where we have a really small number of users (in the 10's, mostly backend systems). Whenever we tried using it in production for sites serving 1000's of users daily, it would crash leading to loss of session data.
On one of the production environments we manage, we're using MSSQL 2005 Express to manage the sessions, the site has 10K+ users a day and 200K+ pages a day. This is a recommended approach in case session is a must and tightly coupled into your application.
If you're about to user MSSQL Express as your state DB, remember that it doesn't come with SQL Server Agent meaning there's no tasks scheduler running in the background and cleaning your expired sessions. I'd recommend finding a scheduler and running the clean expired sessions stored procedure periodically.
Good luck
Instead of messing around with SQL, send your tests directly into one of your IIS nodes to see if you still get the same issue. I'm sure if your only doing a small number of tests StateServer won't be the issue.
Try setting the domain name of the asp.net_sessionid through code to ".yourdomain.com".
By default the ASP.net_SessionID cookie domain name is set to the full application path. So, this may be one of the reason why the cookie is not travelling.
E.g.
Request.Cookies["ASP.NET_SessionId"].Domain = ".yourdomain.com".
Remember the first "." is important in the domain name.
You could do this in the HttpModule in the AcquireRequestState event.
My team is working on a crappy old website and most of the pages are still ASP classic. However, we've recently migrated to forms authentication using ASP.NET and wildcard mapping. Everything works surprisingly well except for one thing: logged in users are timing out too quickly. After looking in the logs it appears people are timing out exactly after 20 minutes (which is the specified timeout due to inactivity).
So, our hypothesis is that the ASP classic pages are not tripping whatever mechanism in the forms authentication framework that resets the inactivity timer. I've googled around and even read the wildcard mapping post by the Great Gu but still can't find anyone else who is having this problem. So, 1) Have you ever seen this problem? and 2) What's the best workaround? (other than manually placing a hidden frame in every janky ASP page that loads a dumb .NET page in the background)
Update: slidingExpiration is set to true
Also: We can't use perpetual sessions because we need the application to time out after 20 minutes of inactivity. Also, this terrible site was written so that the interface is usually stored in the page. There's no simple piece of interface code I could slip the JavaScript into. We tried to put some js into an include file that was called by about 80% of our pages but it's caused some esoteric problems with file download buffers so we may have to try a different tack. Thanks.
Create a perpetual session.
Essentially you end up emitting some JavaScript and an image tag in your master page or navigation users controls (whatever you're using for consistent navigation). This JavaScript on some interval changes the source of the image tag to an http handler endpoint (some .aspx, .ashx) which returns a 1x1 pix clear gif as a response for the image. The constant request ensures that idle pages will keep the session alive.
As long as a browser window is open to your page your ASP.NET session will never time out.
Often the JavaScript will tack on a random number to the request so that the browser doesn't cache the request.
A decent walkthrough is available here.
I am assuming that you have manually created the cookie, in which case your timeout value in code is probably overriding your timeout value in the configuration.
First, if possible (which it probably isn't) don't create the cookie manually, it will save you from not only this headache but dozens of others.
If you must manually create the cookie, make sure that the timeout you are using is actually reading the timeout value that you have set in the configuration file and that sliding expiration is set to true (which you have said it was).
That said, we still have ocassional strange timeout problems when the cookies are manually created. Where I work we implemented a solution which allowed the cookies to be created automatically and timeouts were no longer a problem; however, it did create other issues and we were forced to switch back.