I'm developing an ASP.NET 4 webforms app on my Windows 7 PC. I'm running VS2010 and IIS7.5.
I have a weird problem where after a few page loads (anywhere from 1 to 20ish) I get NO response from IIS. I can't even hit a breakpoint in Application BeginRequest, I just get nothing. But, if I delete all cookies from the browser for the development domain, the website will load perfectly again for a few more requests.
This happens in all browsers I have installed (IE9, Firefox, Chrome, Safari, Opera).
However, if I deploy the app to our hosted server, all works fine.
Anyone had this issue before?
Many thanks for any help you can provide.
After the comments I add for reference here an answer.
This is an issue when you place too large cookie to the browser and browser can not handle them.
The reason that is play here, not play there maybe because of the data that you have type on it and save on cookies.
You can search for cookie limits on the internet and for different browsers. For ie for example http://support.microsoft.com/kb/306070
Try to keep the cookie size as low as you can.
From antmx
For reference, here is what I changed in web.config to fix this problem.
<roleManager cacheRolesInCookie="false" />
Note, though, that now a user's roles will be read from the database each time they're needed, which could cause a performance issue. (I am not think that there is any performance issue and is more secure this way)
Related
I'm currently working on an ASP.NET MVC project and I'm using an azure AD to connect to my website.
When I try first on Chrome, for exemple, those are the cookies that are created :
And every thing works fine ! But if I launch the same website on FireFox without stoping IIS express, I got an infinite number of cookies incoming and the server stop and says :
HTTP 400. The size of the request headers is too long.
And got this list of cookies :
If I close IIS Express and retry an other time with FireFox, it created only 3 cookies and works fine...
Can Someone explain me what is going on ?
PS: Please don't give the solution " you need to delete old cookies" it's not the problem here... It doesn't work even if I don't have any cookies... AND nothing matters what browser i'm using, I've tried 6 differents browsers and every time only the first who has been launch is the only one who works.
Thanks in advance for your help !
Reason/Investigations
I think you have some API or AJAX calls which are secure and require authentication. When you change the browser and your requests are no more authenticated and on AJAX or API call it start creating the cookies. I am sure if you will login to the app in FireFox it will stop doing that. I dont think it is a browser specific issue. If you will move the app from Firefox to IE it will do the same.
Solution
Now, you have to either make sure that when you are not logged in or the request is not authenticated you redirect to login page and stop making unauthenticated calls.
Other solution is to delete all nonce cookies as per MikeDotNet solution.
You will find some people suggesting that it is a bug in Microsoft Nuget package Microsoft.Owin.Security.OpenIdConnect and if you use 3.0.0 it will fix the problem. It works in some of the cases but I found that solution good for IIS but not in Cloud.
I was just shutting off the pc at work, and I had to quickly check if something was fixed. But I clicked on my mobile google chrome browser for the desktop and went to test if a bug was fixed or not.
This is where the trouble started, all of a sudden I couldn't hold session. I could login on the web application, but I couldn't hold session. Weird character strings were put in the url each time I logged in but I just couldn't get my browser to hold session. I checked the browser settings, I deleted all cookies, I restarted the browser, etc. Nothing helped to hold session.
While testing I noticed I was using my mobile google chrome browser, where after I checked with the normal google chrome for desktops I was able to hold session.
Im using the normal asp.net authentication implementation, nothing important is custom. But its rather disturbing for maybe future expansions to mobile platforms.
Any of you people know what could've caused this error? Is it an error in google chrome (mobile)? Is it possible
Make a file called generic.browser in a folder called App_Browsers and put this in it:
<browsers>
<browser refID="GenericDownlevel">
<capabilities>
<capability name="cookies" value="true" />
</capabilities>
</browser>
</browsers>
This will fix the problem that cookies aren't enabled. Apperently this is fixed in ASP.NET 4.5.
Source:
http://www.hanselman.com/blog/FormsAuthenticationOnASPNETSitesWithTheGoogleChromeBrowserOnIOS.aspx
This is because Cookies are probably disabled. Forms Authentication relies on Cookies.
Mobile chrome occasionally tends to do that with mvc3 and mvc4. I'm not sure if anyone yet knows why. Having cookies on and setting the UseCookies in Web.Config doesn't help. Furthermore, I'm not sure if Web Forms is affected. But since I've seen this only in Mobile Chrome, I'd say it's something Google needs to fix.
I am facing a problem where ASPXAUTH cookie is not being generated unless the website is hit from the same machine where it is hosted. I have confirmed this by enabling and viewing IIS logs.
From all other machines no matter what, it redirects back to the login page. This is a very strange behaviour as no installation has been made nor any changes to IIS. I would appreciate if anybody could share their experience and suggest a possible solution.
UPDATE : For some unkown reasons it is working with Firefox. Still not able to figure out what is causing this in other browsers !
After 2.5 days of intense searching and hair pulling it turned out that server date/time was not correct !!! I synchronized it with internet clock and cookies worked.
Do you have security settings where you don't allow cookies in the other browsers?
A tester of my new app reported problems with authorization support in ASP.NET MVC app: Whenever he switches to a new tab (different controller), he's prompted for his login again.
After investigation, I found that the server forcibly wants to use cookieless forms authentication using URLs such as in this question.
The problem appears in his Firefox 3.6.15. Not on other browsers on his computer, not on Firefox on other computers. I checked his Firefox options: Cookies are enabled. HTTPfox even says there is an ASPNetSessionId exchanged!
How come? Can anyone shed some light? FWIW, my web.config doesn't say anyhting about cookies or sessions. I didn't even know of these cookieless URLs before seeing them on this computer and doing some research.
Uninstall and reinstall Firefox from his machine. backup his bookmarks first so he doesnt lose anything. It sounds like its an installation issue rather than a coding problem.
We are noticing some very strange behavior on an installation of a .NET2-based webapp on Server 2008. Our app uses old school Integrated Windows Authentication and simply reads the LOGIN_USER server variable from the request collection. There's a good reason for this, but that's somewhat irrelevant to the question, since the underlying WindowsAuthentication code from ASP.NET does the same thing.
Anyway...
When you enter the URL in the browser, it loads up just fine and displays the username (from LOGIN_USER) no problem.
When you click on a link within the web app, it loads the page just fine and authenticates without any problems.
When you hard refresh (Ctrl-F5) it also works just fine.
However, when you click open in a new window or open in a new tab, the LOGON_USER variable is blank
Any ideas? Am I missing some IIS7 setting somewhere?
Tested clients are Windows 7 with IE8 or Windows XP with IE6.
I experienced something very similar on IIS6 a few years ago. The issue then was caused by both anonymous and windows authentication being turned on for the site. Turning off anonymous authentication fixed the issue.
Though this was on IIS6 it might be something to look into.
The problem went away on it's own............ for now. After a reboot. Really. Shoulda thought to reboot earlier.
Also: anonymous auth was not enabled (otherwise, LOGON_USER would always be blank).
So, if you ever encounter this problem.... reboot!