We have an Asp.net MVC 4 website that has been in production for several months with no problem. Until this morning, that is. All of a sudden people could only log in via IE. Chrome and Firefox both failed. After a bit of panicked debugging we found we could only log in if we set the forms timeout from
<forms loginUrl="~/Login" timeout="30" />
to
<forms loginUrl="~/Login" timeout="120" />
Can anyone tell me why this is? Nothing has changed in server configuration, and that field hasn't been changed in web.config from the initial deployment.
Related
I am having issues with a third party site we are using to process credit card payments posting those payments back to our site (ASP.NET MVC) and the ASP.NET_SessionId getting lost. This is happening in Chrome exclusively. I believe it's due to their recent SameSite which you can read about here. I can see when inspecting the cookie in chrome that the Send for attribute on the cookie is set to 'Secure same-site connections only' but locally it says only 'Secure connections only'.
I have made the necessary changes to my website locally and have this working but once pushing those changes to our live webserver (Windows Server 2012) I am still having issues with Chrome.
Here is my relevant web.config settings:
<compilation debug="true" targetFramework="4.7.2"/>
<httpRuntime targetFramework="4.5.1" maxRequestLength="4096"/>
<sessionState mode="InProc" cookieless="false" timeout="60" cookieSameSite="None"/>
<httpCookies requireSSL="true"/>
<authentication mode="Forms">
<forms name="RAMAUTH" timeout="60" slidingExpiration="true" cookieSameSite="None"
requireSSL="true"/>
</authentication>
The webserver has .NET 4.7.2 installed.
I think that's everything I need to do in order to get this working and like I said it works locally but not on the live webserver. Another thing I noticed is when using the configuration editor in IIs (8.5) on the webserver it errors telling me it does not recognize the 'cookiesSameSite' attribute.
Am I missing something? Is there a logical reason as to why this would work ok locally but not on a live webserver running IIS?
I am using ASP.NET State Server, while using the website, following message occurs occasionally
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
As soon as the ASP.NET State Server service is restarted it gets fixed and of course all sessions are killed.
If In-Proc is used then nothing like this happens.
What could be the reason?
Try this:
<httpCookies httpOnlyCookies="true" lockItem="true" />
<trace enabled="false" localOnly="true"/>
<sessionState cookieless="UseCookies" regenerateExpiredSessionId="true"/>
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="30" slidingExpiration="true" />
</authentication>
Solved, i was trapped in a recursion.
And, the funny thing about this is that FireFox didn't let me know because FF was terminating the request and returning with the error. While, Internet Explorer kept running which made me think what is wrong and why it is taking that much time!!! and i found the recursion.
I must be doing something wrong. I have followed instructions to set the timeout on my forms authentication app, but the app never renews the cookie and will time out about every 15mins or so.
I must be missing something that is so obvious it is not mentioned in the literature.
Here is my config info:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" defaultUrl="~/" timeout="120" slidingExpiration="true" cookieless="UseCookies" />
</authentication>
and the session state
<sessionState mode="InProc" customProvider="DefaultSessionProvider" timeout="120">
...
I have tried sliding or not sliding--same time out happens.
Dumb questions: do I need something in the code behind (VB) on every page to make sure the postback renews the authentication?
If you are browsing your web application from IIS then check the check the Idle Time-Out(minutes) property under "Process Model" of application pool.
If it is 20 minutes. You should change that property value.
I have been developing an ASP.NET MVC 4 (with razor) WebApp, that worked great in Debug, and even in Release on my local machine.
Now I uploaded it to the server, and while you are navigating it suddenly, from time to time closes your user session, asking for username and password again.
Any idea of why? Maybe I am losing some configuration or settings requirements, but its driving me mad.
It looks like you are confusing Session with Authentication. You probably need to enable FormsAuthentication.SlidingExpiration Property so you aren't automatically logged out.
<authentication mode="Forms">
<forms loginUrl="member_login.aspx"
name=".ASPXFORMSAUTH"
cookieless="UseCookies"
requireSSL="true"
slidingExpiration="TRUE" />
</authentication>
I think that your Session expires after 20 minutes. take a look here:
What is default session timeout in ASP.NET?
Also you'll find the solution for your problem, that is to set Session timeout..
So we have been stuck on a connection timeout issue and we are lost.
All pages on this asp.net web application times out after exactly 2 minutes.
Saying:
connection timed out
description: connection timed out
All articles on the internet suggest it is the asp.net web config setting "executionTimeout". (Here is ours)
<httpRuntime executionTimeout="3600" requestValidationMode="2.0" maxRequestLength="15360" />
But obviously ours is set to way above 2 mins. A colleague of mine also fiddle with the iis settings without success.
Any suggestions?
EDIT: This does not happen on debug at all, which makes me lean towards it being an IIS issue.
EDIT: We don't believe it to be an asp.net session issue since we are still logged in and can browse to other secure pages after this happens
Resolved: So after some more investigation we discovered that the timeout issue was just from when accessing the website from within our intranet. Apparently we have some daemon software (Websense) running on the network that was the root of all this evil.
The above you mentioned should work, Look for the following in your web.config file (maybe its a issue of session timeout):
<system.web>
<authentication mode="Forms">
<forms timeout="20"/>
</authentication>
<sessionState timeout="20" />
</system.web>
Increase the timeout time you are using.
Hope this helps.