In web.config I've configured forms authentication as follows:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx"
timeout="20"
slidingExpiration="true"/>
</authentication>
Initially the ASPXAUTH cookie is set correctly. Using Firefox's cookie viewer I can see the cookie and the expiration period is correct (20 mins).
Sliding expiration also sets an updated cookie correctly (20 more mins added).
But after that any new http request (even if made within the next 5 mins) will result in 302 error and redirects to Login.aspx as if authentication has expired.
Application details below:
target asp.net 4
iis 7.5
shared hosting but with dedicated pool (recycling did not help).
Login.aspx uses the asp Login control for authentication (no custom cookie).
Any ideas?
This could have many reasons.
Is this happening on your local machine, too? Have you maybe configured a httpCookie Domain in web.config which doesn`t match your local host environment?
Have you configured a machinekey (validation/encryption)? This can be important in load balanced scenarios.
Do you use dynamic content caching in IIS?
Have a look into your event log. Per default 302 errors based on a failed forms authentication are logged there. Are there any entries telling why you have are considered being unauthenticated? It could help identifying the root cause (ticket expired, could not be decrypted etc.)
Also keep in mind, that the expiration of a forms authentication cookie is not extended on each request. A forms authentication cookie is refreshed after 50% of the original timeout has passed (in your case 10 mins). So configure your session timeout appropriately.
Related
I have a very strange behaviour on my production server that only happens a few times during a week. On a form login POST a redirect is sent to what looks like a cookieless URL like:
"/(F(kD5qGnK-0b5L80VYgScenFuCnjQsLR67HhXq-BWXS1hL45hhqL8AiLlEyB-9CuJgutiyXzN42w8Bo_cm2o73GFWP_fuQ1AtPfXSaB7odZYAOBnuNW3Yy873fQDpRzYgOVo3Ee48gaCbS7FUIyOBA3CksCTZ3N6YCZ7pcZylZEo01))/SiteSpecificPath/CMS/edit/"
What normally happens is a redirect to just "/SiteSpecificPath/CMS/edit/".
This in turn leads to a redirect loop going back to the login.aspx page and continuing like that.
I don't want to use cookieless so the question is how this is triggered? And is there a way to disable this behaviour? I have looked through all levels of config files and cookieless is set to false on all places.
The site is an EPiServer CMS site, but in this case it seems to be related to a normal asp.net forms login procedure that for some reason triggers a switch to cookieless URLs.
I have found some references about cookieless triggering a redirect loop, but in my case the strange thing is why it even starts using cookieless URLs in the first place.
I have also done debugging using advanced logging to see all headers sent from the browser, but I don't see anything strange there. Cookies are sent as normal, including the ASP.NET session cookie.
EDIT: This is not an access problem. A given user can normally login, but sometimes this redirect loop is entered.
Some details: IIS7 on Windows Server 2008 R2, EPiServer 6 R2, ASP.NET 4
Possibly the user doesn't has access to the redirect URL and this is why it redirects everytime to login page and continues like that.
Firstly check if the user is authorized to access the page in the redirect url.If the user isn't authorized, redirect to a page that the user can access Or update the access rights for the user.
I don't want to use cookieless so the question is how this is triggered
When using FormsAuthentication, Check your Settings for same in web.config. As seen below this has a property cookieless which can have options as AutoDetect,
UseCookies, UseUri, and UseDeviceProfile.
<authentication mode="Forms">
<!-- Detailed configuration options -->
<forms name="MyForm"
loginUrl="Login.aspx"
timeout="30"
cookieless="UseCookies"
... />
</authentication>
So, in your case the value for cookieless seems to be either : UseUri OR AutoDetect, although UseDeviceProfile is possible too.
UseUri:If this configuration option is selected, cookies will not be used for
authentication. Instead, the runtime encodes the forms authentication ticket
into the request URL
AutoDetect:Results in the use of cookies if the client browser supports cookies. Otherwise, URL encoding of the ticket will be used.
UseDeviceProfile :: Results in the use of cookies or URL encoding based on a device profile configuration stored on the web server. These profiles are stored in .browser files in the c:[WinDir]\Microsoft.NET\Framework[Version]\CONFIG\Browsers directory.
Since you don't want to use cookieless, set the value for cookieless to UseCookies.
NOTE: When using the setting cookieless="UseCookies" , requires the client browser to support cookies. If the browser does not support
cookies, forms authentication will simply not work. As
it will never receive a valid authentication cookie from the browser, ASP.NET
redirects back to the login page over and over again, and you end up in an
endless loop of presented login pages
I want to detect when a asp.net Form Authentication ticket has expired. I then want to log to the server the user that was signed out because of inactivity. Is there an event that fires on the server when the authentication ticket has expired?
<sessionState mode="InProc" timeout="5"></sessionState>
<authentication mode="Forms">
<forms loginUrl="~/Home/AccessDenied" timeout="5" />
</authentication>
In the global asax file, I have tried the Session_OnEnd(). But the context.user object is null. When i call membership.getuser() it returns null also. I have tried making the session timeout before the auth but that doesn't help. I am using mvc3 and ii7.5.
Session and forms authentication have two completely separate timeouts.
See my posting on this here:
How can I handle forms authentication timeout exceptions in ASP.NET?
In Application_PreRequestHandlerExecute you need to check the ticket.
Also be sure your session and forms auth timeouts are in sync using the code I posted there. Not just setting both to say 60 minutes. Since forms auth doesn't update the 'touched' time until half of the time passes by, and session time is updated on every request, they get out of sync.
In my ASP .NET web application, when I first navigate to the login page, I do not see a Set-Cookie header coming back in the response from the server. I expect to see one that looks something like:
ASP.NET_SessionId=efypn5ihkam3pdcuucmbykvi; path=/; HttpOnly
Here is my sessionState config entry in the web.config:
<sessionState mode="InProc" cookieless="false" timeout="480"/>
I've cleared my cookies in my browser, then navigated to the login page. No Set-Cookie. After I log in to the application, it does send a cookie back for session tracking.
Other apps I've built work fine...this one is giving me trouble. Any ideas?
Usually, the session state isn't started until you create your first session state variable, which usually begins with authentication (after logging in). Unless your deliberately creating a sessionstate variable on the login page request, you shouldn't see one until you actually log in.
I had this problem that when I signed in with local host iis there were no problem but when I signed in with my site the session cookie and login cookie was not set.
The problem was in web.config that I hadn't sync that with my webserver.
I'm using Forms Authentication in my current ASP.NET Web Application (not MVC) and my IIS 6 server is configured with the following options:
in the [directory security tab] -> [Authentication Methods] I have:
the anonymous access Enabled
Integrated windows authentication Enabled
Do the above options prevent Forms Authentication from working properly? In other words, what is the proper IIS 6 configuration for Forms Authentication?
EDIT
I just made test with the two options above enabled and the Forms Authentication session expired and redirected me to the login page, but all the answers so far advise that [Integrated windows authentication] should be off!
Here is a check list for using ASP.NET Forms Authentication on IIS6
Configure IIS:
In IIS, Site Properties -> Directory Security -> Authentication and Access Control
Enable Anonymous Access
Disable all Authenticated access methods
Configure Forms Authentication:
Configure Forms Authentication in your site's web.config:
<authentication mode="Forms">
<forms name="MySite"
path="/"
loginUrl="~/logon.aspx"
protection="All"
timeout="30"
slidingExpiration="true" />
</authentication>
Your name and loginUrl may vary. The slidigExpiration attribute is used to keep extending the forms authentication cookie lifetime rather than just kicking the user off of the site after the timeout has expired. The timeout value is in minutes.
Configure Session Timeout:
You need to configure your session state timeout to be longer than your Forms Authentication ticket expiry. If you don't do this then an idle session can time out the session but leave the user logged in. Code that expects Session values to be present will throw exceptions because they are gone even though they are still authenticated. The timeout value is also in minutes.
<sessionState mode="InProc" timeout="40" />
Because forms authentication does not rely on IIS authentication, you should configure anonymous access for your application in IIS if you intend to use forms authentication in your ASP.NET application.
See here http://msdn.microsoft.com/en-us/library/ff647070.aspx for more information.
The anonymous access should be enabled, I don't think integrated windows authentication makes a difference but if you're not going to need it then it's best to turn it off. The important thing to remember is to make sure it's turned on in web.config:
<authentication mode="Forms" />
Here's a basic tutorial that might be useful:
Overview of Forms Authentication
Anonymous access -> checked
All other option on the security tab -> unchecked
Note, forms authentication is done by .NET - not by IIS. Also, Windows Authentication MUST be off as well.
Rather technical explanaitions by MS.
Per a question I posted yesterday, our website's DNS structure has changed to round-robin DNS which literally swaps back and and forth between two production servers. Our web.config for both prod servers has:
<sessionState mode="SQLServer" ... > pointing to the same shared DB
A machineKey on each server that is consistent between the two (this was the main point of my post yesterday).
[update] The same domain in the <forms domain=".mydomain.com" ... > tag
When we use the login feature on the site, the login actually makes a web service request to a 3rd website that authenticates a user. If the resulting response says it was a successful login, then we use FormsAuthentication to log the user in:
FormsAuthentication.SetAuthCookie(strUserID, true);
Our issue is that on some pages we see we are logged in, others we're not. Is this something indicative of either us not completing a final step to share session between two prod servers or could our SQL server session DB be broken?
Thanks in advance
UPDATE:
Our code to determine if the user is logged in is quite basic:
HttpContext.Current.User.Identity.IsAuthenticated
UPDATE 2:
When I hit prod1.mysite.com (or prod2.mysite.com) I get a cookie called "ASP.NET_SessionId" but when I hit the live public URL, www.mysite.com, I don't get this cookie. Is this part of the problem?
RESOLUTION:
It turns out that everything we did here was all correct and that our live site which uses Akamai was being cached in various states due to Akamai's cache configuration. Sharing your logged in state between servers has been confirmed to work.
One thing you could do is use the Firebug add-on for Firefox to ensure that the authentication cookie is being sent to the browser as expected after logging in although as you are seeing that you are logged in on some pages I would expect this to be the case.
Another thing to check would be that the domain is set correctly for the authentication cookie and that it is valid for all pages on your website.
This is typically set in you web.config in the forms tags, example below and should be same on each server in the web farm.
<authentication mode="Forms">
<forms name="yourAuthCookie" loginUrl="/login.aspx" protection="All" path="/" domain="mydomain.com" timeout="30"/>
</authentication>
If this is all correct then it is possible that session is not being shared correctly between your servers although the settings that your have described in your question appear to cover what is needed.