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.
Related
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.
I have 2 asp.net web applications using Forms Authentication setup to have cross application authentication. I have placed the following code in webApp1 and webApp2 web.config files within the
system.web tag.
<forms timeout="11520" loginUrl="https://App1/logon.aspx" cookieless="AutoDetect" name=".ASPXFORMSAUTH"
protection="All"
path="/"
domain="fsenet.companyname.net" />
</authentication>
<machineKey
decryption="AES"
validation="SHA1"
decryptionKey="306C1FA852AB3B0115150DD8BA30821CDFD125538A0C606DACA53DBB3C3E0AD2"
validationKey="61A8E04A146AFFAB81B6AD19654F99EA7370807F18F5002725DAB98B8EFD19C711337E26948E26D1D174B159973EA0BE8CC9CAA6AAF513BF84E44B2247792265" />
Scenario 1 Works: If I try to access a page on webApp2 and I'm un-authenticated it will redirect me back to webApp1 logon page, I then logon and are redirected back to the page on webApp2, All works as expected when using this redirect method.
Scenario 2 Problem: If I Log on using webApp1 and have a link on a page within webApp1 and try to navigate to a page within webApp2 I automatically get redirected back to the logon page. As I understand it I should be already authenticated to access the page on webApp2 and should not be asked to authenticate again.
I use this code to identify if I'm authenticated
User.Identity.IsAuthenticated.ToString()
Scenario 2 shows False reason for redirection and Scenario 1 shows True.
Am I missing some setting that allows me to access the content on webApp2 after Authenticating with webApp1?
It is very important that you set FBA settings correctly for cross-application SSO. There are already blog posts covering such tricks, and I can see that you missed multiple steps, and then one app cannot get the authenticated info from another.
http://geekswithblogs.net/bjackett/archive/2009/09/03/single-sign-on-across-.net-web-apps-using-forms-based-authentication.aspx
Ok what I was doing wrong was not access both sites with the same domain e.g. while I was debugging I was logging in via
http:/localhost/Site1
(localhost being the mistake) and then linking from their to http://domianname.net/Site2/Page1.aspx when I should have been accessing them both via http://domianname.net/Site1 and http://domianname.net/Site2/Page1.aspx (Both the with the domain) which allows the authentication cookie to be picked up from the correct location I believe.
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 have a login cookie for www.mysite.com and several sub-domains, eg.:
www.one.mysite.com
www.two.mysite.com
www.three.mysite.com
In IE only (firefox does not do this) if I log on in mysite.com, it appears as though that cookie is shared across all subdomains (logged in to all sites). If I log on using a subdomain (one.mysite.com), the cookie is not shared (only logged into one.mysite.com).
www.mysite.com and www.one.mysite.com share the same web.config file, and I don't mind them sharing a login cookie (it's the same site with a different url is all), but not across the rest of the sites.
How do I stop IE from sharing the cookie to all or some subdomains?
Can I do this just using the web.config file?
Update:
I'm using membership and role manager in my web.config file. In the above problem I have not set
<authentication mode="Forms"> <forms domain="...
As far as I can see,
<authentication mode="Forms"> <forms domain="mysite.com" ...
can either allow only one domain (www.mysite.com), or all subdomains (.mysite.com). I need a way to allow www.mysite.com and one subdomain. Is this possible?
Can I tell the other subdomains not to accept the .mysite.com cookie?
Normally a cookie set on example.com will be accessed by all of the subdomains. However, if you want to limit the cookie to a specific subdomain, you should manually set the domain property for each domain you want them to access.
Response.Cookies["domain"].Domain = "www.example.com";
Some valuable reading, or More valuable reading... (read: "Limiting Cookie Domain Scope" section), and finally "How to limit cookie for a particular subdomain in ASP.NET"
The answer is that I really have no idea what is going on with the login procedure here.
The other guy who I'm working with is fixing the problem. Apparently it has something to do with the machine key, which needs to be changed on all the other subdomain websites (two.mysite.com, three.mysite.com) except the main one (www.mysite.com).
This is hardly an answer, but if you're stupid like me (don't know enough about ASP.Net logins), and have to deal with IE8/compatibility view and this login problem... Well hopefully it will help someone who doesn't know where to look for an answer.
If I use
<authentication mode="Forms">
<forms
cookieless="UseUri"
slidingExpiration="true"
timeout="60"
/>
</authentication>
Once you have made this change.When visiting as an anonymous user, the URLs will look exactly like they did before. For example, when visiting Default.aspx page my browser's address bar shows the following URL:
http://localhost:2448/default.aspx
However, upon logging in, the forms authentication ticket is embedded into the URL. For example, after visiting the login page and logging in as Sam, I am returned to the Default.aspx page, but the URL this time is:
http://localhost:2448/(F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2))/default.aspx
Note: cookieless authentication tickets are more prone to replay attacks since the authentication ticket is embedded directly in the URL. Imagine a user who visits a website, logs in, and then pastes the URL in an email to a colleague. If the colleague clicks on that link before the expiry is reached, they will be logged in as the user who sent the email!
This is one possible drawback if I use cookieless authentication ,I am interested in knowing other possible drawbacks of this approach.
Thanks
Disadvantages:
limited amount of data that can be stored in the URL (especially in mobile and Windows 2003 platform)
Cookie replay attack (that you already mentioned) - can be avoided using ssl, and limited using timeout.
Your URL looks long and not "neat".