Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 1 down vote favorite

I have an application running using asp.net authentication and SQL Server sessionState mode. For some reason, the session seems to never expire one one of our environment.

This is an extract from the web.config file:

<sessionState mode="SQLServer" timeout="1" allowCustomSqlDatabase="true" partitionResolverType="Microsoft.Office.Server.Administration.SqlSessionStateResolver, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" sessionIDManagerType="Lanap.BotDetect.Persistence.CustomSessionIDManager, Lanap.BotDetect, Version=2.0.15.0, Culture=neutral, PublicKeyToken=74616036388b765f" />

As you can see, the application is hosted in a load balanced MOSS2007 instance, so it has a custom SQL parameter for the sessionState DB.

From my exploration of SO, the most common problem with this seems to be a disabled SQL Server Agent or a missing/not running SQL Server Agent job. I am positive that it is not the case here. I went to the ASPStateTempSessions table which hosts the sessions, and checked that its behaviour is coherent. When I login to my website, a line is created with a session id, and 1 to 2 minutes later it is destroyed (session expired). But if I then return to my website, and refresh it, instead of being logged out, I'm still logged in. If I then go to the ASPStateTempSessions table again, a new line is created with the same session id.

As far as I can tell, session ids survive weeks... Rebooting the computer where the browser is doesn't change anything. Clearing the cookies does. Obviously the cookie in the browser is triggering the recreation of the session on the server.

Also, I am positive that I am not running in cookieless mode. First I can see the cookie in my browser, and also the URL it goes to does not include a sessionId (which I was led to understand is a discriminating criteria to know if one is running a cookieless session).

I have several environments. One is working (our Live server), one is not (our Demo server). When comparing both web.config files, the difference that is most likely to mean something is this:

Live server:

<authentication mode="Forms">
  <forms loginUrl="/_layouts/ClientPortal/login.aspx" />
</authentication>

Demo server:

<authentication mode="Forms">
  <forms loginUrl="/_layouts/ClientPortal/login.aspx" name=".ASPXAUTH" domain=".shlsolutions.net" protection="All" path="/" timeout="2880" />
</authentication>

The reason for this difference is that the application needs to be able to use cross-domain authentication on the demo environment.

I am quite sure something has to be changed in the web.config file, but I don't really know what. Can you help me with that?

Edit: cookie copy/paste

.ASPXAUTH=BDEBD7975B717219A24D8D2FB22ADF523F4E63C9619B758A9F500CC2C9967156A9CFDB057A2DFC4DF9157A1D6E0F6EA3FBBA90C3D566FEB9E7F63AA4DBBDF68A32A5518175F6073E81677069C8205D9433306DCE331921237189DEECE59B6C7494EA6369C6D1BEAE544E83295D942DCE856718C5B095D695DB42D68BF75991A5EE37246E37B96F1675547E87338B89FE669EFD2A5AB38A15F7926025791F8FC17A02882B; path=/; domain=.shlsolutions.net
ASP.NET_SessionId=pa5v0f2mnc20jybxq4bmbr20; path=/; domain=uat.central.shlsolutions.net; HttpOnly
.ASPXAUTH=D3DCB91EA8705E7350AB2BEDBDC79F37C87CB391AFF81A9F07CAE72DB7BDBFA2AA62B1EF538C7EF77C7874D84A09DCDADF186884190B9BEDA56E73E9A1EED1948A6C75E618D4FD7AA9344C234B6472E3BEEC088911112877E7A77A6E2B27CA8EF69BE20B38591EDB9706225FA9831890B1C4684B3D9075153CB22CC37140F8C05811C44853DC3E7278740B7BBDC55627E801D81ED8EE8ABC07AA8CFF1F3F59EED9606ABB; path=/; domain=uat.central.shlsolutions.net; HttpOnly
__utma=164265915.107905765.1350568100.1350661280.1350898679.7; expires=Wed, 22 Oct 2014 09:37:58 GMT; path=/; domain=.uat.central.shlsolutions.net
__utmb=164265915.1.10.1350898679; expires=Mon, 22 Oct 2012 10:07:58 GMT; path=/; domain=.uat.central.shlsolutions.net
__utmc=164265915; path=/; domain=.uat.central.shlsolutions.net
__utmz=164265915.1350568100.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); expires=Mon, 22 Apr 2013 21:37:58 GMT; path=/; domain=.uat.central.shlsolutions.net
share|improve this question

2 Answers

up vote 0 down vote

ASP.Net Session state uses a sliding expiration mechanism which by default should expire the session state object after 60 minutes of not hearing from the client for which the session was created.

There is a known issue that SharePoint never cleans up these session state records out of the ASPStateTempSessions table: http://blogs.msdn.com/b/toddca/archive/2009/03/17/sharepoint-session-state-the-guest-that-just-won-t-leave.aspx

Hope this helps?

share|improve this answer
no, I checked and the table gets cleaned. I see the line get created and deleted with the session expiration... – Evren Kuzucuoglu Oct 21 '12 at 12:02
have you left 60 minutes to pass? otherwise the session did not expire! it's sliding expiration as opposed to absolute expiration. – RoManiac Oct 21 '12 at 17:44
I'm positive. Whether I leave the default timeout value, or change it to some smaller value, I can go to the table itself and verify that the line gets deleted - that is because the session expires. Then, whenever I start my browser again (even 3 days after), the line gets created again - the cookie triggers the recreation of the session with the same session id. – Evren Kuzucuoglu Oct 22 '12 at 8:15
up vote 0 down vote

Looking at your web.config it looks like you have a custom session ID manager. Documentation: http://captcha.biz/doc/aspnet/api/captcha-web-reference.html#BotDetect.Web.CustomSessionIdManager The behaviour you experience might be caused by what this custom session ID manager does. This DLL is used for Captcha, is it an option to take it out from web.config and see if the situation improves?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.