I've implemented mixed mode authentication in our MVC 5 application and everything seems to be working fine apart from one niggly problem.
When I browse to the site in Chrome the following page is displayed:
This site can’t be reached
The web page at xxxx might be temporarily down or it may have moved
permanently to a new web address.
ERR_UNEXPECTED
The main page is actually loaded, but I'm concerned that this might confuse users. The error doesn't appear in Firefox, IE or Edge.
I'm assuming it's down the redirects I'm performing during the login process, but I'm not sure why Chrome is showing the error.
The basic process is:
Forms authentication process checks if user is logged in
If authenticated, redirect to desired page (or default)
If no, redirect to signin action
Signin action then checks if single sign on is enabled, if it is then the user is redirected to an area of the site which can handle windows authentication. Otherwise they are redirected to the normal login page
User is then either authenticated using windows authentication, or redirect to login page
Just looking for any ideas as to why this error is only shown in Chrome
I ran into the same behavior with chrome briefly displaying the above error before loading the page. I narrowed it down to a chrome issue while handling the http2->http1.1 downgrade caused by using windows authentication (HTTP2 doesn't support windows authentication).
I ended up working around the issue by disabling http2 on the server. No real downside in my case since all the sites were behind windows authentication so the connection was always being downgrade to http1.1 anyways.
The following chrome bug has more detail.
My organization had a web app that worked perfectly in iOS 6. You'd visit the website, the website would tell you to add the page to your homescreen, and boom, a nice HTML5 web app was added to the home screen.
Because we're processing sensitive data, the web app used HTTP authentication (via the native WebKit auth dialog) to authenticate user/passes. It worked without a hitch until iOS 7. Now when someone tries to summon the HTTP auth dialog, nothing happens. It's clearly trying to load something, as the spinner in the status bar appears, but no dialog ever pops up, essentially breaking the "app."
Has anyone else run into this? Is this something you'd consider to be a bug on Apple's end? Any workaround?
My company ran into this last fall, starting with iOS 6, and what we have been able to ascertain is that it is a genuine Apple Safari bug as part of its security "enhancements". No real explanation from them for rationale, but here is what we see in the debug and packet sniffers.
In normal operation, the Safari browser will request a page (or an object in the page) from the server on a GET. If that asset is protected with an Access Control List, in our case Apache Basic Auth, and it is the first request on that host in the session, the server will respond with a 401 HTTP response header indicating to the client (the browser) that it needs to request again, this time adding a basic auth header that has authorization credentials. The browser then presents a login dialog to the user, where they can enter user and pass credentials, and either submit or cancel the request. On submit, the client re-requests with those credentials in the auth header.
Assuming the credentials are accepted on the second GET request, the proper asset will be returned on the response, and the document in the browser will proceed with loading the rest of the page (assuming it was a page you requested). If you have embedded assets that reside on a different host, and that host requires authentication for that asset, the process is repeated as the page loads.
Here's where it gets broken. If you embed calls to objects from more than 2 hosts total on the same page, which require basic authentication, the 3rd authentication prompt on that page is suppressed, so the browser spins forever waiting for you to enter credentials on a prompt that you never see. Your Safari browser is now hung up on that stalled authentication prompt, on this and any other tab, even on a reload, and you will not get another prompt unless and until you hard-close your browser or restart your device.
This does not affect Chrome, just Safari, and it is both on an iPhone and an iPad with iOS 6 or later. I have the latest iOS version as of this writing (7.0.6), and the problem is still there.
We had a workaround last year, where we would create an internal page that had an array of each of the embedded hosts, which we would then loop through with an iframe embedding a call to the favicon.ico at that host's location. That worked until recently, where now, perhaps because of the iOS 7 feature of freezing background tabs, the auth prompts are frozen up again.
Here was the JavaScript sample:
hosts=["store","profile","www","secure-store","images","m","modules"];
devhost=location.hostname;
var i=0;
while (hosts[i])
{
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain');
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>");
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>");
i++;
}
The second set in the document.write would give a visual indication of which hosts have been authenticated, as their favicon is now displayed. It also lets you know which host might be stalled, as its icon is missing.
Since this workaround stopped working on iOS 7, the only cumbersome solution we have is to pre-open a separate tab for each of the favicons (directly in the URL), enter the auth, go back, go to the next one in the list, and repeat until you have cached all of the auth credentials for all of the hosts used on the page. At that point, you can load the original page since your creds are now cached. Cruddy, and completely unreasonable for an end consumer, but is what we need to do for testing sites that are behind a public CDN, as we need to protect assets on that development site with an ACL.
As of today, we are still figuring out a better workaround. Not an issue on Android, Windows, or any other iOS.
Sure worked better when Jobs was alive.
Hope some of this helps.
I have the exact same problem. Basic authentication worked with previous iOS versions but not with iOS 7 in combination with web apps added to the home screen. I think this may be related to the dialog problem described here.
Standard dialogs are not working at all, such as alert, confirm or prompt.
The login prompt that is shown to authenticate the user is probably blocked (does not work or is not visible) and that is why the web app does not pass through the authentication phase.
I suppose Apple will have to fix this bug in a future release.
Edit: After upgrading to iOS 7.0.3 basic authentication suddenly started to work again also in home screen web app mode. Login prompt is displayed and everything works as expected.
I switched to the iPhone user agent during which time I visited Google, then I changed back to the default Firefox one again. I cleared all of my history, cache and cookies but Google still thinks I am on a mobile device and insists on directing me to the mobile site. I have checked my user agent and it is definitely the correct one and I have removed every single cookie in Firefox.
How is Google remembering this information? Is there some other sort of mechanism apart from cookies that remembers user settings? It doesn't do it in any other browser.
I've seen some issues such as this on Firefox. Which add-on are you using to change the UA?
To be absolutely sure what the UA String you can Check you User Agent String
Also you can check for cookies using the Fire Cookie Add-On
Normally i can fix this issue by Closing the web browser and starting up a new instance of Firefox.
My other issue with Firefox is that it caches HTTP redirection rules from a website, so if i change a HTTP redirection rule on the server Firefox does not immediately pick this up - This problem is also fixed by closing the web browser.
I solved this problem in firefox by resetting my default agent:
Tools->Default User Agent->Default User Agent
and then going to:
Tools->Clear Recent History->Cache
I've created a basic MVC 3 website that's using Windows Azure's Access Control Service (ACS) to perform user authentication against an Active Directory Federated Service (ADFS) endpoint. I followed the "Add STS Reference" wizard and the site runs fine and authenticates users just perfectly in IE. However, when I use Chrome or Firefox it continually prompts for my credentials over and over again.
I found this post on technet that mentions the issue as it pertains to Firefox but there's no fix for Chrome mentioned, nor do I feel like the steps required to fix Firefox are practical in the real world (i.e. I can't expect end users to do this)
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx
Has anybody else hit this snag? What am I doing wrong?
With some help from a Microsoft Rep (Adam Conkle) over on TechNet (scroll down to the comments), I finally have an answer to this problem.
Turns out, the ADFS website that performs authentication of users (this website gets setup in IIS during the installation of ADFS v2.0) is by default configured for Integrated Windows Authentication (IWA). IWA is configured in IIS to use Extended Protection for Authentication (EPA) and therein lies the problem. Apparently, most other browsers don't support EPA yet which is why Firefox & Chrome continually prompt for credentials in a loop.
Two options...
Keep using IWA but turn off EPA in IIS for the website (described here)
Turn off IWA in favor of Forms-based Authentication (described here)
I had the same issue, sort of. I had 1 person who was being prompted in Chrome and another that was not. On a hunch, I looked at the trusted sites. The person who was being challenged had the intranet site in their list of trusted sites. I removed it and tried again. This time they were not challenged.
Thought I would put that out there in case anyone else has this issue.
I am using DotNetOpenId and Asp.NET MVC. I have the following problem:
When using IE not problem I can login and when I check the Page.User.Identity.IsAuthenticated I get true. If I test this in Safari for Windows the Page.User.Identity.IsAuthenticated is false. If I use Safari in Mac I can Login without a problem.
Any Idea? What Other Info can I give you so you can Help me?
Thanks
You are logging into your web site using Safari, right? I can't tell from your question whether you expect to be able to log in using IE and then switch to Safari and still be logged in. But that's certainly not possible.
Can you tell me more about what happens when you're using Safari? Does the login appear to finish but then it still behaves like you're not logged in.
With the release of Safari 4, all started to work.
I had a similar problem to this a while back. It turned out that the cookie I was setting capitalized the first letter of the domain when set and the javascript we were using was looking for all lower case. This worked fine on every browser but one... Safari for Windows treated Example.com and example.com as two different domains and saw the cookie request as a cross-domain and blocked it.