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.
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
Got a site still in dev that uses ServiceStack's Open ID implementation to sign in users. It's been working fine all this time, suddenly today morning Google's OpenID login started failing, Facebook still authenticates fine. No error is thrown, just redirects back to the default url with this appended to it:
#f=Unknown
On my localhost it works flawlessly, both Google and FB login ok, only in production does it fail. I have tried quite a lot:
Re-verified each and every file in my asp.net bin folder compared with local and production, no difference.
Re-routed the production domain name to my localhost (in the hosts file), in hopes to step through the creation of the session. No luck, still signs in flawlessly.
Connected via remote desktop to the server and tried logging in on it as localhost, fails. (yea, WTH?).
Is there a way I can get a log of what is going on as the authentication is happening? or does anyone have an idea of what could be the issue?
On a side note: I recently changed dns settings for the domain name and moved it to this new server, but that was around 3-4 days ago, and it's been working fine all this time, until today morning. Also noticed that a reverse DNS lookup on my IP resolves to a different domain, investigating that right now.
UPDATE
This issue reared it's ugly head again this morning. I'm not sure what could be causing it but I suspect windows automatic time synchronization to be somehow throwing things off. I'm turning it off and going to keep an eye on things to see if it returns. Also, this issue seems to throw my SSL settings into chaos, i have to manually reset IIS's SSL bindings in order for things to work, even WebDeply is affected. Very strange.
UPDATE 2
Issue happened again today. I'm now suspecting it's somehow related to IIS's web deploy feature cause it happened immediately after I published my site. Also now realised that I don't need to reboot, a simple iisreset seems to fix it. Will keep monitoring.
FINAL UPDATE
I finally found the culprit. Time. My virtual server was gaining time very fast and every few days it would be ahead of most other servers and so the authentication would fail. The limit seemed to be around 3-5minutes, within that range, the authentication works okay. More than that, it fails. To get around it, simply enable time syncing and it should not re-appear.
You can check your production server clock. The OpenID request synch with the internet time in order to validate the request. If the clock is off or it was off for a while just reboot and the problem will be solved.
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.
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.