I have an application that requires Windows authentication with fallback to Forms authentication. I built it in this way: http://msdn.microsoft.com/en-us/library/ms972958.aspx and everything works fine.
So basically I create forms authentication cookie for a domain based on the outcome of Windows authentication. The cookie is valid as long as the browser stays open. I do not have problems with that in Firefox or Chrome, not even IE8 on Windows XP machines. Unfortunately all Windows7 machines with IE8 experience the same problem: a login prompt shows up when you try to refresh the page after around 30minutes of inactivity. Even if I provide valid Windows credentials I still cannot log in to the application. Nothing helps, but closing the browser and starting it again. Then I am again logged in automatically and it will be fine as long as I stay active. After 30 minutes of inactivity - again log in prompt. After some research I found out that if I delete the auth cookie using developer tools (F12) and then refresh, I get automatically logged in without the prompt (just what you would expect from Windows authentication).
Does anyone of you have an idea what can go wrong and how can I get it to work correctly on Windows7 machines? Or maybe ideas on where to look? Is it IIS problem (I use IIS6 on Windows 2003 Server), client problem? What makes Win7 IE8 so special that it fails?
I don't know why it expires, but I managed to get rid of the problem. Somehow on IE8 on Win7 it cannot continue, because it tries to auth, but the old auth cookie is supplied. If I clean the cookies on the request and then forward to the login page, it works. It's not a solution to the problem, but at least the user gets re-authenticated...
Related
I can't find any clue about this problem, what make me wonder if I am wrong from basic knowledge.
I am building an application with mongo, nodejs (with passport), and react.
Users can log in into this application correctly in normal windows browsers.
Session cookie is set with passport, and the flow is working.
Problem starts, when I tried to log in through Incognito Mode from google chrome (or any other browser).
Is any problem about cookie session in Incognito Mode?
Should I use other method to go over this case?
I think it is not relevant any code of how I set cookie session, but if someone need it I will paste it.
I'm using Firefox 79 and since some update month ago I get the basic auth password prompt each time when opening the developer tools. This happens on a password protected staging site.
The curious thing is I logged in before and an auth cookie is set so I can browse the site after that. When opening the developer tools the password prompt shows up again. When I close it and hit refresh I'm still logged in.
When inspecting the server log it shows another GET request is made to the current page in the moment opening the developer tools. But it seems the auth cookie is not sent in this one request (401 Unauthorized). Navigating the site with dev tools open after this automatic request then works without logging in again.
I wonder why this automatic request is happening and/or why the auth cookie isn't sent here?
I have a windows 2008 R2 Server, my apps use framework 4.5
<compilation targetFramework="4.5.1">
but suddenly one of my apps stopped authenticating against my authentication app in the same server. others do, others just dont the page the page redirect well to the auth site and auth ok, but on the way back to my app the page show the error"connection reset" each time I Try, I see a warning in the event viewer
Exception type: HttpException
Exception message: Cannot redirect after HTTP headers have been sent.
If I try this app in another server or local in my computer it authenticates just fine.
So I think is a matter of WIF versions installed on the server, but I'm Not sure.
Exist any way to know What Wif Versions are installed?
Thanks
Solved,
It was due to miss information on the third app webconfig, was the certificate information was invalid, so it tried to find a certificate that didnt exist on the server.
Firefox was working perfectly before we've updated it to version 30.0. It seems that the new version does not like our Proxy setting which needs users to auth with their AD accounts.
In the past version, Firefox will pop-up a box that allow you to type in the username and password, which works perfect. However, it does not pop-up anymore and gives me this error message.
The following error was encountered:
Cache Access Denied.
Sorry, you are not currently allowed to request:
http://www.google.com.au/url?
from this cache until you have authenticated yourself.
I try to manually set up the username in key chain and allow firefox to access it but Firefox seems do not access that key chain at all.
Is anyone have the issue with the proxy which needs authenticate in Firefox30.0? Does anyone know the possible solutions?
Many thanks!
Shuopan
trouble shoot update-----------------------------------------
Quite interestingly, Firefox will work for 1 minute after I am using Safari with that Auth proxy. However, if I am not touching Safari for 1 or 2 minutes, Firefox will stop working and pop up the similar error message.
tried network.http.use-cache = false but not work
Thanks
We find Philipp's solution is helpful.
This might be due to the disabling of certain insecure authentication protocols in firefox 30: https://www.mozilla.org/en-US/firefox/30.0/releasenotes/#whatsnew
You can do the following:
Enter about:config into the Firefox address bar (confirm the info message in case it shows up)
Search for the preference named network.negotiate-auth.allow-insecure-ntlm-v1. Double-click it and change its value to true.
https://www.mozilla.org/en-US/firefox/30.0/releasenotes/#whatsnew
I am building a small web application and in my application I am using the session object to store information across calls to server. This works quite fine in Firefox \ Chrome\ IE, but it seems to fail in Safari. In Safari the session keeps forgetting that I've stored values in it.
Why is this happening? what can be done?
The session is based on an id stored in a cookie. The server uses this Id to link to your session on the server. It's highly likely cookies are off here. Load up fiddler or turn on tracing to see what cookies are being sent over... You should see the one with aspnetsessionid in it, if not your browser prob has them turned off.
You may also want to take a look over here: Facebook API and Safari
Looks like, if any redirect is sent when you are establishing cookies, they will be viewed as 3rd party cookies and could cause issues with your server-side.
if your settings on Safari are set to not allow cookies, then this fails. I have just had the same issue on an iphone web app im writing. I enabled cookies and all worked fine.
The whole idea of the Session is that the values are stored server-side. Safari can't possibly cause the server to forget something. Either the value wasn't ever stored in the Session or Safari is failing to render the Session value.
Trying using a debugger to confirm if the Session holds the correct value when passing the value into the Session and when you're attempting to retrieve the value from the Session.