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.
Related
I have a rails app with sorcery for authentication. I'm trying to get Stripe checkout integrated but I'm seeing an issue with Safari. Works fine with Chrome and Firefox.
I can successfully create a Stripe hosted checkout page with the cancel url and the stripe js sends me there in the same browser tab. Problem is when I click on the cancel/back link on the checkout page it goes back to my app and punts me to the login page as it can't find the session and current_user is nil.
Funny thing is that on the login page if I simply type in the cancel url into the address bar it authenticates me successfully so it must find the original session/cookie.
Has anyone encountered this? Is it a caching issue? I see no errors in the log nor in the js console. Just this in the server log...
Filter chain halted as :require_login rendered or redirected
And it's nothing to do with Stripe either as I created a simple test.html page on another server and different domain with a link to the cancel url. Same result. I see the same issue going from https back to my localhost server as well as in a staging environment https -> https.
I've also cleared my Safari cache, history, cookies, restarted the browser and my computer and cleared the rails sessions table to no avail. I'm using activerecord session store but also tried with plain cookies.
Any hints/solutions would be appreciated. Thanks!
This is apparently a known bug with Safari as of Feb 19 2021. Safari won't send the cookie if it's set to Lax. Rails 6 defaults are lax now where < 6 is wasn't set.
PWA Freezing after OpenID authorizes user [iOS Safari Standalone]
I have built a simple PWA for our security staff that allows employees to click links and view content about our company's policies on various matters. The app uses Microsoft's OWIN middleware library to authorize our employees' access into the app via their enterprise Microsoft login creds. When a user clicks the 'Employee Sign in' prompt on our login page, they are redirected to Microsoft's domain to complete the sign-in process. Once sign in is complete, they are redirected back to our app's home page.
The Problem
The problem appears only to arise when iOS users (v13) pin the app to their homescreen and then launch the app in standalone mode, and only after the user has completely terminated the app and then returned. We've tested the app on Chrome, Safari (non-standalone mode), Firefox, and the issue does not present in those browswers. The app functions seamlessly up until the point that the user has completed their Microsoft signin and been redirected back to the home page. At this point, if a user clicks a link to another page (within the app), the app completely locks up, doesn't respond to further button clicks, and doesn't load the page prompted by the user. No errors are thrown in the console.
What we've found immediately kicks everything back into gear is if the user switches to another app (even just for a second) and then switches back to our PWA when it's locked up. At this point, the page that the user attempted to navigate to loads immediately without further prompting and the app works 100% seamlessly after this point. It's only the initial version of the default page that freezes.
Potential Causes
My current working theory is that the problem is being caused by some combination of the following:
Redirection to Microsoft's sign in portal. When the user is sent to Microsoft for auth and then sent back to our domain, there could be issues with session/cookie continuity.
iOS's standalone mode. In conjunction with the above, is it possible that using third-party authentication and briefly leaving the domain of the PWA is causing problems with future page navigation. This is supported by the idea that no other browsers or devices have this issue, and my research suggests that Apple support for PWAs is still in its early stages.
Service worker failure. We have done significant testing to ensure that a service worker is being properly installed and registered when a user first enters the site. We have checks to re-register the SW just in case it is dropped at any point in page navigation. We are confident that at the time a user is redirected back to our home page after authentication that there is an active service worker that handles page GET requests. I have also tested explicitly caching the linked pages accessible from our home page during the service worker's registration to see if serving the page from the cache would alleviate the issue. It did not. This is the code in sw.js that handles fetch requests (taken from Google's handy guide):
// "cache-first" approach for requests from client. Will try to get the file from the cache.
// If no match found, it will send the request onto the network. If both fail serve fallback page.
self.addEventListener("fetch", function (event) {
if (event.request.method !== "GET") return;
event.respondWith(
// Try the cache
caches.match(event.request).then(function (response) {
console.log("[service worker] attempting to fetch file from cache...");
return response || fetch(event.request);
}).catch(function () {
// If both fail, show a generic fallback:
return caches.match(offlineFallbackPage);
})
);
});
I have remotely debugged the PWA in standalone using a Mac, and what I have verified is that the click event that fires when a user clicks a link to navigate to a new page IS being properly handled, so the problem truly appears to lie in the loading of the linked pages themselves. Beyond that, debugging remotely has confirmed that there are no HTTP GET errors (or any other errors) firing at all when attempting to navigate to other pages on the site.
This is the first PWA I've ever built and I'm a novice with all this stuff. So I'd love to know if I'm missing anything or where I can go from here. I've scoured all the forums and can't seem to find answers anywhere. Thanks!
I had a very similar problem in my very specific case. but my pwa (packaged with PwaBuilder) froze on oidc signout, when redirect to applications home url.
In XCode I observed an error stating:
could not signal service com.apple.webkit.webcontent 113 could not find specified service
The problem did not occur with my Identity Provider redirect back, but with the following redirect which initiated the OIDC client library which I am using oidc-client-ts. It turns out that there are two possible ways to set the location/url of a window, assign or setting href. And the library uses assign by default. Changing assign to replace href lead to my iOS PWA not to freeze anymore. Very specific use case but it might help somebody else...
auth.signoutRedirect({
post_logout_redirect_uri: process.env.BASE_URI,
redirectMethod: "replace",
});
We have an application that is using ADFS for authentication. For the single signout we are redirecting the application to the url https:///adfs/ls/?wa=wsignout1.0.
The Application gets redirected to the URL without any issue but the signout is not working in INternet explorer. In Chrome and Mozilla this single signout is working fine without any issue.
Has anybody face this issue and what was the workaround?
How do you detect that "sign-out does not work"? I guess, what happens is:
you call https:///adfs/ls/?wa=wsignout1.0 and sign-out actually takes place
you visit a Sharepoint page again and IE does not ask you the user credentials, letting you in at once. But this is OK, because at this moment a new sign-on automatically takes place. (You probably may notice that when you revisit the SharePoint page there is a roundtrip to ADFS visible in the browser's address bar).
Actually, from your post, I believe it is working correctly from everywhere. However, since you are using IE and likely on a domain joined machine you are silently signed in with desktop SSO (i.e. windows integrated authentication). For example, if you signed in from outside your corp network on IE and then signed out and signed-in again, you will see the behavior to be different.
Thanks
//Sam (Twitter: #MrADFS)
I do have the same issue. As mentioned, it is an expected behavior when we sign out from within the network. On an external network, you should be prompted for credentials after redirecting to sign out URL. However, it doesn't work in Internet Explorer and Edge.
It does work fine in Chrome and Firefox. The only work around I found is to clear the cookies manually on the IE browser and then redirect to sign-out URL. However, it's hard to expect end user to clear their browser cache manually.
Regards
Prasad
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 am trying to integrate my Rails application within another application using the "iframe" technique.
The hosting application has an iframe like that:
<iframe src="http://10.0.0.106:3000/" width="800" height="500">
</iframe>
This frame retrieves and displays the login page, which is ok. But when I type in username and password to login, it seems that authentication fails and I am prompted again for login. Note that no normal "Wrong username/password" message appears (as it is done when I give wrong username of password). The login form is displayed as if it were the first time I visit it.
Any clue?
If the CSRF token is included on the page the only problem that you should experience with iframes is this IE weirdness :
http://www.sympact.net/2008/07/rails-and-ifram.html
Is the iframe being served from another domain? This is probably a security feature.
You could turn off the security feature (probably a bad idea), or try other methods of authentication.
"Yes. It is served from another domain."
— Comment above.
Reason why you are not getting an error message is because the authentication doesn't fail. The cookie that's being stored is for '10.0.0.106:3000' and not your current application. I wouldn't be using an iframe to handle authentication. (Why are you doing this anyway?)