I've been using Devise in an app for a while and it all works fine for me in all browsers (Safari, Firefox, IE6, 7, 8 etc)
I have a new user who has a fairly locked down version of IE8 and as soon as they try to access the app, before they even get to the login page, they get a Windows Authentication prompt appear. If they try to enter the login details they have been provided it fails. I'm not really worried about it failing, as the authentication prompt shouldn't be appearing.
I've tried suggesting allowing cookies etc, but they are still getting the problem. Has anyone got any suggestions as to other things we could look at?
It appears the upgrading to Rails 3.0.5 and Devise 1.2 resolves this problem
Related
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.
Every time google chrome comes with a new version it breaks something very badly and then how we can explain to users? Do they trust, that "The google" can do this?
Anyways, here is the issue.
Browser - Chrome 42.0.2311.90 m
Issue - Rails site, with Devise gem, is working fine in FF, Safari and old versions (tested on 41.0.2272.118) of chrome. But, does not work with the above mentioned version and user is not able to login into the system.
This has been verified on all other browsers, also checked that there are no code changes which can do this.
Any help would be great, this really is annoying because i am sitting for this since last 5 hours just checking the google chrome settings for cookies.
I have developed a CMS using casein plugin. When I run locally (localhost:3000), everything works fine (login, logout, navigation, etc.). When I push to my main site, and try to login, I get this error:
The webpage at http://.com/admin has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.
I have tried clearing my cache/cookies and no luck. I even tried deploying to dev..com and same issue resides. The weird thing is, if I run script/server on .com or dev..com and go to .com:3000 or dev..com:3000, it works fine and the redirect issue does not exists... Before I post any code, has anyone ever seen this before? For some reason my before_filter is not picking up the session when not running script/server. Any thoughts?
One case that might cause this:
Your authentication mechanism redirects unauthenticated users to root_path
root_path tries to authenticate a user and redirects to the sign in page
We're experiencing a really bizarre bug in our Rails 2.3.4 app.
This bug only happens in Internet Explorer (7 and 8). Here's what happens:
A new customer creates an account at https://domain.com/signup/free (notice no subdomain)
Their account is identified by a subdomain like "example.domain.com"
After signing up, they get a welcome screen with a link to their account's home page
They follow the link, then click the "log in" button and attempt to login
Even though they provide valid credentials, the app redirects back to their account's root url ... they can never reach their admin area
The only way they can login (on IE) is by quitting and re-opening IE ... then it works fine ...
Something with their initial session is preventing them from logging in. If it matters, we are using restful_authentication and the ssl_requirement plugin ... I'm not sure if one or both of those has a problem with IE but we are stumped here.
Also, I've read IE has an issue with subdomains that contain underscores ... this isn't what's going on.
If the domain of the session cookie is set to 'domain.com', try setting it to '.domain.com' instead.
I don't know if this works with 2.3.4, but
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] = '.domain.com'
used to do the trick.
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.