views:

29

answers:

1

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.

A: 

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.

Andy Rose
I checked the forms authentication cookie after logging in and I noticed when I hit each prod server own its own, e.g. prod1.mysite.com and prod2.mysite.com, for each of those sites my cookie has the domains prod1.mysite.com and prod2.mysite.com respectively. When I login via the live public URL, www.mysite.com, that cookie has the domain www.mysite.com. Does that mean I should set the `domain` in my `web.config` for `FormsAuthentication` to ".mysite.com" so that all instances of where you log in use the most generic domain match.
Mark Ursino
Yes, cookies will only ever be sent with the request if the domain set in the cookie matches the domain of the url of the request. The domain specified in your web.config should be the same on each site in your web farm and should be the domain that is used to access your site via whatever Network Load Balancer you are using. Hope this sorts the issue. I have updated the answer with this detail.
Andy Rose
Thanks for all of the details. I've made the `domain` change and we're still having issues. I've updated my question with more details.
Mark Ursino
Really not too sure what the issue could be now as your code looks fairly standard and correct. I would for, sanity's sake, check the cookies that are being sent to the browser using firebug or web developer add-ons in firefox to ensure the domains are set correctly.
Andy Rose
Hmm, just noticed something about the `ASP.NET_SessionId` cookie. Made an update above. Any thoughts?
Mark Ursino
I'm not 100% sure but I don't think this is set until something is actually stored in the session.
Andy Rose
So, we determined the issue is that the live site uses Akamai to cache a lot and that was causing the wrong states to be cached. Our configuration was correct all along. Thanks for the help/tips!
Mark Ursino