Website works only in Private Mode and not in Normal mode
Hi,
we have a website that runs without any issues on Chrome/IE/Firefox (private mode only). When we browse the website in Firefox (normal mode) it logs in fine but subseqent HTTP GET/POST are automatically redirect to our login page without any errors in the network/console developer tools.
If we disable the cache in Developer tools then the website works without any issues in Normal mode. This has started happening from last 2 months (hopefully due to the chagnes in Firefox)
Any advice on how to diagnose the problem will be helpful
Thanks in advance.
All Replies (13)
I'd try a refresh, personally
The Refresh feature (called "Reset" in older Firefox versions) can fix many issues by restoring Firefox to its factory default state while saving your bookmarks, history, passwords, cookies, and other essential information.
Note: When you use this feature, you will lose any extensions, toolbar customizations, and some preferences. See the Refresh Firefox - reset add-ons and settings article for more information.
To Refresh Firefox:
- Open the Troubleshooting Information page using one of these methods:
- Click the menu button , click help and select Troubleshooting Information. A new tab containing your troubleshooting information should open.
- If you're unable to access the Help menu, type about:support in your address bar to bring up the Troubleshooting Information page.
- At the top right corner of the page, you should see a button that says "Refresh Firefox" ("Reset Firefox" in older Firefox versions). Click on it.
- Firefox will close. After the refresh process is completed, Firefox will show a window with the information that is imported.
- Click Finish and Firefox will reopen.
You might try the "Forget About This Site" feature. This deletes cache, cookies, permissions, and cached files for a specific site. Here's how:
- Open the Library window using Show all History (Ctrl+Shift+h)
- In the small search box at upper right, enter enough to uniquely identify the site -- we want to avoid accidental misclicks with this feature
- Right-click a matching history entry and choose Forget About This Site
Because Firefox modifies a number of files, this may take some time to run.
Any difference?
Note that using "Forget About This Site" will remove all data stored in Firefox for this domain like history and cookies and passwords and exceptions and cache (bookmarks are excluded), so be cautious. If you have a password or other data for that domain that you do not want to lose then make sure to backup this data or make a note.
You can't recover from this 'forget' unless you have a backup of involved files.
If you revisit a 'forgotten' website then data for that website will be saved once again.
Thanks for the help guys, but I have tried this by installing Firefox on a VM and then directly accessing the website and it straight away redirects me back to the login page.
I also have tried the above steps as you all have suggested but no luck. Is there anything else I can try to diagnose the issue
Do you notice any differences between Firefox and Chrome in the HTTP headers sent with the requests?
On inspecting the request headers, when using firefox the websites .ASPNETAUTH cookie is missing in the request and hence being redirected to the login page.
Surprised on why its not having the auth cookie once it logs in. I can see the Auth cookie on the response to the home page on successful login.
Request from Firefox once successfully loged in below
GET /Home.aspx HTTP/1.1 Host: devapp.styleanalytics.com User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: keep-alive Cookie: ASP.NET_SessionId=mspwhmxjxxkydemyubcgknvc; isMobileDevice=False Upgrade-Insecure-Requests: 1
Request from Chrome once sucessfully logged in
GET /home.aspx HTTP/1.1 Host: devapp.styleanalytics.com Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36 Sec-Fetch-Dest: document Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Accept-Encoding: gzip, deflate, br Accept-Language: en,en-US;q=0.9,es;q=0.8 Cookie: _ga=GA1.2.1346646913.1557933993; isMobileDevice=False; .ASPNETAUTH=999052475FDECC1AD9B1C979C1FDE9DA32BDDEE54A9BF637603E44FE218EA6278781AF93DC79B97494B4A97FC5195C5EF9B58A07CC25FC37537EDCFD40F3CDF5036A01B01D768814790CDC4B67EE11FE726B2FAD1AEECAF78214F53DF7642675B31492923D4F06E2693890039FE18E438E624B4197C0177B9B73A4DD52D7FDD9697244F43A455FFC4A0A0FD30BE1FDC75C1DD071FDABB974A6122457DA9B9F2D12133CAECB0D2EC44315836A996718F3E8EAB9C10DFB6631C7A4CB6F9CD70635; ASP.NET_SessionId=mz4wqbtzevzk02ttaulsypzv
Do the Chrome devtools have a cookie inspector similar to Firefox's Storage Inspector (Shift+F7) to see whether all four cookies are set on the FQDN or whether some are set on the base domain? I think it should work either way, but maybe it would be a clue.
Yes, chrome has the cookie storage similar to Firefox. I have attached both the screenshots from Firefox and chrome.
In chrome I can see the .ASPNETAuth cookie where as Firefox does not have it.
Also i am seeing some strange behaviour with respect to how firefox works in certain isntances.
In one case i had the .ASPNETAUTH cookie (visible in Firefox Cookie Storage) but when the request is made its not included in the request cookies and hence gets redirected to the login page.
This is all in Firefox version 74, but on different machines
Modified
Is your Firefox screenshot showing the cookies visible from the login page, or the first page loaded after login?
Is the auth cookie anywhere in the global dialog on the Options page, Privacy & Security panel, "Manage Data..." button. I would think it is either under a slightly different domain or possibly not being set at all for unknown reasons.
The firefox screenshot is of the first page after login.
In certain scenarios the auth cookie is set and visible in the storage, but any request made does not include it in the request cookies(screenshot attached)
Any chance the links or form submission URLs do not use the identical host name?
No, the request is to another page within the same domain.
Firefox very randomly (approx 2% of the requests) decides to store the auth cookie in the cookie storage but does not send it across in the request header.
Hi rajeshsv_5
I suggest filing a bug with steps to reproduce on a publicly accessible website.
https://bugzilla.mozilla.org/enter_bug.cgi
Cheers!
...Roland