I use Devise in my Rails 3.1 application to manage sessions. In Safari and Firefox, the user is correctly prompted to login if he attempts to access a page that requires authorization. However, in Internet Explorer (versions 7 and 8), the user is correctly redirected to the login page, but logging in does nothing.
In other words, the username and password are correct, but it appears as if Internet Explorer can not set the session. Cookies are enabled for IE as well.
Has anyone experienced any similar session issues with IE? I just need to know where to look. I have already fought through IE's inability to handle pushState, it seems like IE is pretty difficult to code for.
Internet Explorer 9 seems to work fine.
Crossbrowser pushState with hashbang fallback: History.js.
AJAX requests without the XRSF token destroy the devise session, maybe IE is messing this one up with your code.
Related
I've been trying to work out authenticating users into my app, which is running inside a MS Teams Tab application, and I'm having issues in mobile.
To authorize requests in the application, we just need to have a cookie in place that the server sets when the user authenticates. So for this to work inside Microsoft Teams, I've been trying to just send the token to the iframe and set the cookie. Everything works pretty well on web and desktop, but on mobile (I've tested only with iOS so cannot really tell about Android), the cookie doesn't work at all.
I've tried to set some test cookies and read them, and it doesn't work. So my question is if there is a way to work with cookies in mobile? Is it an issue on my end or has it been disabled in the web view that loads the tab? Is there a way around it or any suggestion that would help solve my problem?
Thanks for the help!
I am facing very interesting issue and I am not sure what can cause this. I am using SSO SAML for authentication to the system and IE11 as the browser to access the application. After some time (e.g. 5 min) the session terminates and it is renewed and it is a background process. Somehow only in IE, the session is not renewed until I maximize the browser and do some user action (after that it works). Other browsers are not affected and everything works in background properly. Do anyone know what can cause the issue in IE that the browser needs to user action?
I understand that Watir and Selenium have issues with NTLM auth when trying to login to web pages for testing. My research indicated that there are two normal work around. 1. add the credentials into the URL 2. use an auto auth plugin/extension. I currently don't have the option of using an extension in my environment, though I'm working on that. So, I'm left with passing credentials.
The problem I have is as follows.
Chrome:
In Chrome I pass the credentials manually (as in I type it into the browser directly) as http://password:user#example.com/ and it opens the page, but does not populate the popup. If I try to manually pass it as http://example.com?username=usr&password=password, it populates the auth pop up but does not proceed.
If I try to automate with ruby using the following code all I get is unknown user name and password. I have confrimed that the usr and pwd are correct.
browser.goto("http://example.com?login=usr&password=password")
browser.goto("http://password:usr#example.com/")
IE
IE behaves a bit differently.
In IE I pass the credentials manually as http://password:user#example.com/ and it returns an error that it can't find the page. If I try to manually pass it as http://example.com?username=usr&password=password, it logs in correctly.
If I try to automate with ruby using the following code the first example throws an page can't be found error. The second example opens the page, but does not populate the popup. I have confirmed that the usr and pwd are correct.
browser.goto("http://example.com?login=usr&password=password")
browser.goto("http://password:usr#example.com/")
What am I doing wrong?
My environment is Windows 7 Pro, IE 11 and Chrome 60.
Found an article that indicates MS removed auth in URL. So it makes sense that pwd:usr# doesn't work. Article ID: 834489
Ok, I have found the answer. After discussing it with my company's senior architect, there is no way to access an NTLM Windows authentication form by design. It's literally designed so that it can't be automated that way as a security measure.
The one workaround that he did suggest as a way to deal with the authentication issue is to use something like C# (our standard) and open the browser with the assumption that the user is already logged in. This will completely bypass the authorization pop up rendering the issue null. I'm unclear exactly how to do this, but I hope this provides a useful direction for others.
Sometimes, the login screen will appear if the user clicks the back button and then chooses another link, instead of the content that should be displayed. It's like the application suddenly thinks the user is not authenticated. The user then has to re-authenticate to continue browsing. This happens while the user is actively browsing, so no timeout should occur, and after authenticating, the content is shown (so it's not an authorization problem).
This problem is unfortunately quite difficult to reproduce. The user who has experienced the problem most often is using Windows XP with IE 7, but the problem has also appeared with Windows XP and IE 8. I can't seem to reproduce the problem on Windows 7 with IE 9 or Chrome 18, but because the problem is difficult to reproduce, I can't say confidently that the problem is browser or browser version dependent.
Our ASP.NET MVC 3 app uses Forms Authentication with role information stored in a SQL Server database, and membership information in Active Directory. Hosting environment is IIS 7.5 on Windows 2008 R2.
Has anyone else seen this problem, and know of a workaround?
On the server, I guess that you are using a custom IPrincipal which you need to reattach to the request thread for each request? Are you doing this in an HTTPModule or in global.asax? What page event are you hooking into to authorize the thread?
I have noticed differences in authentication being available in different runtime contexts dependent on which event I use. I now always use OnAuthorizeRequest and check that application.Context.User != null.
But the symptoms you are describing sound more like the authorization cookie is missing from the request intermittently.
Add some debug logging for each request and monitor cookies and authorization to see if you can detect the conditions that cause it.
I've had Windows Authentication setup on an area of our website for some time now, and it has worked flawlessly so far.
Recently, the login prompt stopped appearing and went straight to "Page cannot be displayed" for some reason.
While connected to our network, the page works fine.
Outside our network, users are supposed to receive a login prompt but they now do not, instead receiving the "page cannot be displayed" error.
Why would this suddenly occur, and how is it fixed? I have tried removing the virtual directory and re-adding it but nothing seems to work.
The strange thing is this is only happening in IE - Google Chrome works fine (I receive the login prompt).
Is there a setting or something inside of IIS that disables this login prompt or something? It is strange it is an IE specific issue as well - there were no changes to the state of IE from one day when it was working to the next where it wasn't.
Anyone have ideas on what might be causing this?
Thanks
Oddly enough, I'd wonder why you were getting the login prompt before now.
If you're logged in to Windows and the site you're browsing to uses Windows Auth, IE will automatically try to pass the logged in user's credentials to the site (this all depends on your domain configuration/trust setup...something may have changed with those settings at the domain level that changed the behavior of your IE).
Chrome/Firefox/Safari don't have this functionality, which is why you're still getting a login prompt.
There is a checkbox in internet options->advanced tab to enable/disable Windows Authentication, but you said that there were no changes. Either way it is something to check.
It sounds like you are hitting a security setting in IE.
IE stops windows authentication information from being sent to sites that you do not trust.
You could try adding the site to your list of trusted sites.
You can start by taking a network trace both Internally and Externally, reproduce the issue and see if the request actually reaches the web server. Also, check the IIS logfile for the "Page Cannot Be Displayed" response.
Let me know if that helps or if you have more questions.
Regards,
Vivek.
You need to take a network capture (www.fiddlercap.com) to get any real help with this.
IE supports the "Negotiate" protocol in addition to NTLM; Chrome and other browsers typically only support NTLM.