I have two sites running on the same server (IIS7 on Win2003).
Site A is my production site.
Site B is a development version of site A. Aside from connection strings in its web.config file, both sites are running the same code.
There are some session variables created in Session_OnStart in global.asax. I've noticed over the past couple weeks, Site A's session variables aren't being properly created. (These variables are used to populate a couple of dropdownlists) This causes the drop-downs not to auto-populate or other errors depending on the page the user is trying to hit.
Site B's session variables have been working correctly. When I hit Site B, the drop-downs populate as I expect.
The first thing I want to try is an IIS reset to see if this corrects the problem, but I'm wondering why my sessions wouldn't be created correctly if both sites are running the same code?
I figured out a solution but I'm still at a loss as to why this is happening.
I wound up coding defensively to handle the session variable I'm interested in not being properly initialized. When this happens I've got code that properly sets the variable. (In all the years I've been a .NET developer, this is the first time session has been an issue)
I can rule out most of the common causes - I know the session wasn't timing out, and I know no updates were made to web.config or any IIS settings (it's a production site, so nobody touches IIS without putting in a support ticket, and the only person who puts in support tickets for IIS is me).
This seemed to be a problem when users clicked on a particular link in the site. For some reason visiting this particular page caused the session variable to be lost. I'm at a loss to explain the why but at least I've got the code working and not throwing an exception anymore.
Related
I have very strange problem. I use ZfcUser as authentication module. I made a lot of projects on lot of different environments using ZF3 and ZfcUser module. I have nevere experienced such kind of problem which I will explain bellow. In my current project I cant login into system on production server. I succesfuly log from local env, or other test environments.
I try to investigate whats going on. I went to login page on production, entered my credentials and system redirects me to home page. No errors, no warnings... notihnig. But I was not logged in. I check the identity from the framework (identity()) - it was null. I thought that may be it is server issue with the php sessions. I checked the sessions on server. It appears that the problem was not there.
The framework succesfully stored the data it needs in sessions. I found the Zend_Auth key, the identity key and the value for logged user. It seems that with php sessions everything is OK.
I am powerless and cant even think about what is going on here and where is the problem. No errors are thrown. I trace the execution of code on local and production environment. Everything is same. The frameworks seems to work properly. But the IDENTITY is allways null
Found the problem.
So, the site was runing under a subdomain. Let say sub.domain.tld. This site is different from main domain which is domain.tld. In the programm code, the favicon of application was requested form the domain.tld not from the sub.domain.tld.
As a result when you hit the http://sub.domain.tld the browser stores two PHPSESSID cookies. One under sub.domain and another under domain.tld which couses Chrome to messed up
Interesting is that, Firefox and IE didnt messed with the sessions and the site was working porperly. I dont say that Crhome is guilty. Obviously the programm code was cousing the problem. But Chrome recognize that one domain is sub domain of the other
Thats why, when I was trying to run project on different environments as local setup or different domain e.g. test.different-domain.tld, ther were again two PHPSESSID cookies set, but in this time Chrome didnt messed up with the sessions becouse test.different-domain.tld is not recognized as subdomain of domain.tld
Very small and silly mistake, but cousing big problems
I've got a situation that I'm a little confused by as I cannot replicate it on any of my other environments.
The site is still in development and therefore has practically no traffic other than the two of us working on it. So if the site is in a dormant state (all IIS instances closed etc) when I first log in the IPrinciple doesn't get set correctly (in time?) and so subsequent security checks obviously fail. I can then immediately go back to the login page, perform an identical log in and all is fine.
This also occurs irrespective of which user I test with so it's not specific to an account.
I can then log in and log out with any user accounts and this never occurs again. This never occurs in Development on my local machine and I also have an instance of the system in my local IIS instance I use as a faux staging environment. I only ever see this on an idle Production environment.
What can I do to prevent this situation from ever occurring? Is this also suggesting there maybe an issue elsewhere?
After having done a bit of experimentation it turned out that the problem was only manifesting in Google Chrome. All other browsers were performing as expected.
The solution was actually an oversight on my part. It seems Google Chrome has stricter rules around how cookies are dealt with in relation to domains.
Setting the domain attribute on the authentication cookie fixed the issue and now Google Chrome also logs in as expected.
Lately we are receiving complaints from users about Page not Found errors on production environment. This happens during Login page load or default page load in the asp.net application.
The application on the production environment did throw the Page not Found error. But when we tried to access the same application from test environment it worked without any problem.
I have read about client-side handling for form submission which results in a race condition with the form being submitted twice. IE 6 turns out to be especially vulnerable to this problem because of how it handles multiple connections to the same hostname.
I am unable to figure out what could be the issue because the application runs fine on other machines and only specific machines give this problem.
Try disabling the button after the first click, therefore blocking multiple clicks. Also have you tried replicating on production? Perhaps it is environment specific.
It was some machine configuration. The infrastructure team could not quite figure out what the issue was, but they formatted the machines which resolved the issues for the user. Not the best of solutions.
Logs did not indicate any detail.
I have an ASP.NET web site that responds with multiple skins depending on the domain that it is accessed via.
The problem is that authentication and some other features seem to suffer random glitches where the user is sent back to the log in screen, or other session controlled values appear to have been lost - but only when accessed via one of the domains. The other domain does not suffer the same issue.
On our test system, the issues DOES NOT exist when accessing via any domain. On live, the issue will happen at varying times during the session, even with identical steps followed. It is for these reasons that I don't think it is a bug in the application software.
On the live system, where the issue is, two websites are set up in IIS, each with bindings to the required domain. One accesses the site through a virtual directory at http://mysite.com/myvirtualdir, the other accesses the site at the root path at http://myalternatesite.com/. I don't think that the virtual directory is the issue however.
I've now solved my problem, though still not sure what the exact cause was.
I opened up website properties for the two websites in IIS, the one that worked and the one that didn't and compared properties.
For anyone else trouble shooting this issue, these are the steps that I took, in order of how likely I think they were to be the cause of the issue.
Second website was using Default app pool. There is nothing particular about the Default app pool settings on this server that would cause session to be lost from what I can see, but I have now changed to use the same app pool as the site that was working all along.
Disabled windows authentication to match the working website.
Changed default documents so that only the required document was listed.
Limited connections to 500 to match the working website.
Hope this is of use to somebody else.
Following recent hardware problems, I attempted to switch a couple of our websites to use new, individual application pools. A test run on our staging server worked fine, and has had no visible negative consequences.
Unfortunately, trying the same operation on our live machine left one of our key applications struggling - my best guess is with some kind of mismatch in Session state. I could log in fine, but a few clicks later would be presented with a screen that was part login screen, but with all menus visible. This indicates to me that part of the system thinks the session had been lost (redirect to login page), but IIS itself had not lost the session (hence the menus showing on the master page).
I tried recycling all the Application Pools (new and old), and each website using IIS Manager. I also tried a single-space change to the web.config file, and a full release of the dll's. Still, I could intermittently use the system for a few clicks, do some useful stuff, then maybe find myself at a login screen again or similar. We have some logging and on some occasions I could see that the session was being timed-out after a couple of seconds, substantially less than the settings on the App-pool (default 20mins).
As soon as I switched the web site's app-pool back to the default, everything was ok again.
What have I missed? Any suggestions gratefully received!
EDIT:
Just thought... on the staging environment I did name the App-pool differently from the website name (e.g. Xxxx_Dev, Xxx_Test etc) but on live I just called it the same name as the website. Could this cause an issue?
do your various applications all use Forms Authentication? Have you specified unique path attributes in each form tag in the web.config under the Authentication tag?
OK. I think I've found the problem.
I was actually using an Application Pool that had been set up by someone else - of the expected name - but they had set it up with the Properties, Performance tab | Web Garden option to use 4 worker processes. I have now changed that to 1.
As the session state was being stored 'In Process' (the default), each time the connection hit a new thread it also essentially lost any stored session variables, as I now understand things.
Its early days, but a simple switch to the newly altered Application Pool (no restarts or web.config saves necessary thus far) and everything appears to be behaving normally.