I have an asp.net website located on some server.
I try to login the website using IE10 compatibility mode, I fill user name and password, and when I press on the "Login" button, nothing happens. I get the login page again.
I checked with wireshark and found out that the cookie is not passed when redirecting from the login page.
I tried the workarounds from this post:
IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
I checked that the date and time of the server are equal to the date and time of the browser, and my server name doesn't contain non alphanumeric characters.
I tried changing the browser settings, restore to default and I tried with or without compatibility mode, but nothing helps!
(in chrome everything works fine and the cookie is passed).
Does someone have an idea about that?
Still cannot post comments...
You can always use cookieless="AutoDetect" to use Uri instead of cookies if it cannot set cookie. Some user may even deny all cookies, that is why all advertisements use only Uri mode.
Though it might result in share of Uri (easier than to share cookies) and if a user shouldn't be allowed to login from different places at once you'll need to revise your login logic.
Related
Scenario:
I have two web applications A and B. A integrates application B in itself via iframe. Application A authenticates a user from B and maintains auth token in a session variable. Now, when application B is rendered on iframe on A and a login page appears, I submit the form and redirect to login but session becomes null. Remember Application A creates a session before redirecting to Login page.
This issue appears in case of IE11 only and when I set its privacy settings -> always allow session cookies on it works.... strange! isn't it.
Check override automatic cookies and then check Always allow session cookies in IE11 and its works fine. However, the same thing works in IE10 without any issue. Any help regarding this.I am already looking into other questions with following links
IE11 does not send session cookie when a link targeting a new tab is clicked (on first request)
IE 11 first-party session cookies being lost in iframe
Does ie11 ignore cookies from site that uses the server's ip as domain?
IE11 does not send session cookie when a link targeting a new tab is clicked (on first request)
Problem solved. Issue was with the IE11 privacy policy as it was destroying session cookies for iframe. As I mentioned above it was working by tweaking its privacy settings.
Set P3P policy on IIS for your hosting site and issue is fixed, now this will ignore IE11 privacy policies
The situation is:
User is on site http://foo.com/ in one browser tab
This site needs to have a link/button that will open https://bar.com/ in a new tab
https://bar.com/ uses basic auth, and foo.com wants to automatically pass those credentials, such that the user is not prompted by the browser.
The obvious answer here is to pass the creds in the URL, e.g. https://user:password#bar.com. Unfortunately, this good old syntax doesn't work in all browsers (doesn't work in the latest IE).
I'm looking for an alternative that would work across all major browsers. e.g. potentially something along these lines:
The foo.com page builds the Authorization header (by base 64 encoding the creds, ...)
Somehow inject those headers into the request that gets sent to https://bar.com/, such that the request gets authorized with no user prompting.
Even if you are able to achieve sending the credentials to the site on the first request, unless the browser knows the contents of the credentials, it will have to prompt the user again for these credentials if the user navigates to another page on that same (bar.com) site that is protected by basic authentication.
If you have control over the bar.com site, then you might consider an alternative authentication scheme that uses a token generated by foo.com, which bar.com then interprets and, if valid, initializes its session to look at a cookie instead of requiring basic authentication for future requests.
Take a look at this question and this one.
Our ASP.NET application is hosted in IIS 7.5 and has the following setup:
main site is hosted under root IIS folder accessible with http://siteurl (1)
we have a separate app in the same AppPool hosted under http://siteurl/Intranet (2)
Main app (1) has Anonymous Authentication enabled along side Forms Authentication (url: siteurl/loginform).
Second app (2) has Integrated Authentication (NTLM).
The login procedure works as following:
User goes to siteurl first
User gets redirected to /Intranet to check integrated auth
If integrated is accepted user gets redirected back with proper auth cookies to siteurl and gets access to the site
If integrated fails user gets redirected to siteurl/loginForm to manually fill in credentials
We have some issues with Internet Explorer (8, 9, 10) that refuses to submit the form data at step 4. It appears to be a known behavior that IE will not POST content to an unauthenticated site once the NTLM negotiation started for that session. I have considered some workarounds for this:
store credentials in a cookie (with JS) and on the server if the POST content has 0 length try to check the cookie values. delete the cookie afterwards
send credentials using GET instead of POST (ugly as we need to make sure the user does not see his just posted password in the browser address bar)
Provide a link to the user to open a new tab and continue the auth process in a separate browser session (this seems to work as IE will happily send POST data from a second tab)
Are there any other options we might have to get around this issue?
From the above 3 which one would be preferable and what unconsidered pitfalls we might encounter?
I wrote about this issue here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Your question omits important information which makes it hard to troubleshoot. You should never see the problem described with the literal URLs you've used, because IE uses protection spaces to decide whether a site is going to demand credentials via a HTTP/401 and example.com/ and example.com/foo/ are different protection spaces.
It would be very helpful if you could share a Fiddler log of this scenario for better troubleshooting.
We use FormAuthentication to manage logins and I have a case where a customer complains where he can login from one computer but to from another.
I can see in my logs that his authentican is successfull but he gets bumped back to the login page. I can reproduce the symptons by disabling cookies so I asked the customer to test if cookies are enabled on http://www.tempesttech.com/cookies/cookietest1.asp, but this came out positive.
What have I missed? Is there any antivirus/security software that can mess up (ASP.NET) cookies?
The user is using IE7 and claims to have F-secure installed.
First ask from your customer to try to login using some other browser like google chrome.
If with other browser works, then ask from your customer to clear the cookies on his browser, if he can clear only your page cookies, then you must be check if you using too much cookies, or too big ones, and create a diferent shecma.
You maybe have set to store/cache the roles on cookie - this make cookie too big ones, and big cookies create problems.
I tried this by disabling cookies in my browser and setting cookieless="AutoDetect" for both the forms element and the sessionState element. however this just doesn't work (what i mean by work is if cookies are enable then the url is unchanged, however if cookies are disabled then the sessionid is added to the querystring as per msdn docs). the only way i can get this to work is if i set it to UseUri which will add the sessionid to the url path regardless of cookies being enabled or not.
It isn't broken, but the browser doesn' report that it has cookies disabled back to the browser.
The browser will report what browser it is, and ASP.NET keeps a list of browsers and browser capabilities. This information is used to determine wether or not to use cookieless when using AutoDetect
From the sessionState page in MSDN:
If the browser or device supports cookies, but cookies are currently disabled, cookies are still used by the requesting feature.
If you're testing from your dev machine have you tried clearing cookies from your browser? There may already be a cookie in your browser that was put there before you disabled cookies.