11

We are using the MongoDB session state provider for our Sitecore 8.1 CD instance hosted in Azure web apps.

We are facing an issue with our CD instance where the session keeps expiring within 1–2 minutes. But the form authentication is still active. I.e. the user is still logged in, but can't access the session; therefore, the user can't proceed with page actions, e.g. submit form etc.

Below is our configurations for session and forms:

<sessionState mode="Custom" customProvider="mongo" cookieless="false" timeout="30" sessionIDManagerType="Sitecore.SessionManagement.ConditionalSessionIdManager">
  <providers>
    <add name="mongo" type="Sitecore.SessionProvider.MongoDB.MongoSessionStateProvider, Sitecore.SessionProvider.MongoDB" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" />
    <!-- <add name="mssql" type="Sitecore.SessionProvider.Sql.SqlSessionStateProvider, Sitecore.SessionProvider.Sql" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" /> -->
  </providers>
</sessionState>

<authentication mode="Forms">
  <forms loginUrl="/login" requireSSL="false" name=".ASPXAUTH" slidingExpiration="true" protection="All" path="/" timeout="120" cookieless="UseCookies" />
</authentication>

Note that we share the same session collection/db between test and uat environments.

  1. If I change the mode to 'InProc', the issue goes away.

  2. As suggested by Dymtro, we stood up separate collections for session and analytics. The issue still persists.

  3. What's the best way to troubleshoot why/how sitecore is identifying real users as bots?

  4. The session time out doesn't occur on our test environment where we haven't implemented this below:

@using Sitecore.Mvc.Analytics.Extensions
@Html.Sitecore().VisitorIdentification()
| improve this question | |
  • 1
    Forms authentication doesn't actually require session state as all the data travels in the cookie, so there's no correlation between Forms Auth working or timing out and Session State working or timing out. – Richard Hauer Oct 9 '16 at 2:20
  • 2
    Further to the above thought, submitting forms / page actions don't specifically require session either. When you say "can't access the session", are you getting a specific error when reading? writing? do you observe the sessions being removed from the database (that's what the Mongo Session provider will do every "pollingInterval")? – Richard Hauer Oct 9 '16 at 2:23
3

I don't believe robot detection is related to your problem. As you correctly suggested in the comments, changing session state provider should not affect robot functionality and the way it overrides session timeout.

Hypothesis

This may be the root of your problem:

Note that we share the same session collection/db between test and uat environments.

The private session store is not supposed to be shared between unrelated instances. The biggest reason for that is the fact that only one instance will be able to handle the Session_End event from the store. If it's not the instance that actually created the session, there will be errors (check your logs on both instances).

Note that this is not a problem with non-sticky load-balanced instances of the same cluster, as all of them are equal. It's only a problem with instances that share the private session and don't share other things, such as the web database, the Shared Session state store, Sitecore configuration, etc. I.e. instances that are not part of the same CD cluster.

Another problem with sharing the private session state is if Sitecore instances don't have matching date/time settings. In that case, one instance will create a session, and another instance may think the session has already expired, so it will remove session data from the store and attempt to process the Session_End event.

Solution

Create a separate session database/collection corresponding to each of your Sitecore instances.

In the future, never share one store between multiple Sitecore instances, unless they have exactly the same configuration and belong to the same content delivery cluster.

| improve this answer | |
  • We stood up separate databases for session and rest of analytics for UAT. The time out issue still persists. – Nil Pun Oct 13 '16 at 0:12
  • @NilPun Then my hypothesis must be wrong, and it is indeed the robot detection that overrides your session timeout. The strange thing, of course, is that this doesn't happen with InProc. In any case, please follow the advice from Mark to make sure your visitors are not handled as robots. – Dmytro Shevchenko Oct 13 '16 at 8:17
  • Confusing. It works with out MVC visitor Identification on Test environment with mongo session providers. Not really sure what's causing this issue. – Nil Pun Oct 13 '16 at 10:14
  • @NilPun are there configuration differences between Test and UAT? – Dmytro Shevchenko Oct 13 '16 at 10:15
  • Yep they are same except connection string – Nil Pun Oct 13 '16 at 21:30
8

I think your sessions are being flagged as "robot". The most common cause for this, is forgetting to include VisitorIdentification on your main layout or main View file.

Webforms:

<sc:VisitorIdentification runat='server'/>

MVC:

@using Sitecore.Mvc.Analytics.Extensions
@Html.Sitecore().VisitorIdentification()

Additional info: https://stackoverflow.com/questions/28626563/sitecore-7-5-mvc-and-httpcontext-session-timeout-set-to-1-min

EDIT: updated to include the following

The easiest way to assert whether it is indeed robot detection that is the root cause, is to disable the automatic robot detection. There is a hidden setting that can toggle this functionality on and off.

<setting name="Analytics.AutoDetectBots" value="false" />

Default value is true. Try adding this to your configs as false and see if the problem goes away.

| improve this answer | |
  • This sounds like the probable cause. I have seen this happen several times when the layout does not have the visitor identification. – ASura Oct 9 '16 at 18:45
  • 2
    hi Mark, if it's related to bot identification, any reason why it works if I change the mode to 'InProc'? – Nil Pun Oct 10 '16 at 4:51
  • There could be any number of reasons; the bot detection code is very involved. Try disabling bot detection entirely as described in my edit above and see if the problem goes away. Would prove/disprove if we are on the right track at all. – Mark Cassidy♦ Oct 13 '16 at 0:32
2

This is happening due to the fact that the session is being identified as a robot.

EDIT 1 You need to solve the issue why the user is being identified as a robot. As an workaround, you may try the follow:

Increase the Session timeout from the Sitecore.Analytics.Tracking.config file. It is found in the App_Config/Include folder.

Search for the Analytics.Robots.SessionTimeout and update the value.

EDIT 2 The sharedsession will get expired after one minute as provided in the Sitecore Documentation. Please see the diagram below:

sessionstate

For more info, please check here

EDIT 3 Robot detection classifies a contact based on IP address, Geo IP information, and user agent.

Robot detection relies on two heuristics to identify robots:

  • A browser that does not carry cookies between requests.
  • A browser that does not support JavaScript or does not raise any mouse or touch events.

You can have more info at those links from Sitecore Official Documentation

1: https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/contacts/contact_tracking

2: https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/robot_detection/configure_the_robot_detection_component

Thanks

| improve this answer | |
  • 2
    Wouldn't it be better to make sure the visitor is not identified as a robot instead of extending all robot sessions? – Gatogordo Oct 9 '16 at 15:40
  • Yes, you are right. – Hishaam Namooya Oct 9 '16 at 15:41
  • 2
    If it's related to bot identification, any reason why it works if I change the mode to 'InProc'? – Nil Pun Oct 9 '16 at 22:17
  • 1
    InProc is the default sessionstate which is private and stored in memory. Please see updated answer at Edit 2 – Hishaam Namooya Oct 10 '16 at 5:17
  • What's the best way to troubleshoot why/how sitecore is identifying real users as bots? – Nil Pun Oct 13 '16 at 0:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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