4

Community,

I am currently having a specific issue with the lifespan of a website visitor's ADF session. Essentially, during a visitors browsing session, the session appears to restart, hence triggering the OnSessionStart again, and incorrectly setting claims that should only be set once.

Does anybody have any details as to exactly what logic is processed in the filter that can cause a new session to be created? Is there a session cookie that is being lost/reset on the visitors browser? etc.

Any information would be greatly appreciated.

Daniel

Improve this question
3
  • 2
    Which web server are you using? If IIS, did you check if the ADF module is running for all requests and not just ASP.NET requests? That could cause a second request to come in (typically for favicon.ico), without an ASP.NET session, and thus result in two sessions when you only expect one. In general, I would recommend that you don't use OnSessionStart but instead use OnRequestStart and then check if the claims you want to set are already present in the Claim Store.
    – Peter Kjaer
    Commented Apr 18, 2014 at 14:40
  • Thanks for the feedback. We are actually running WebSphere Application Server 7.0. Any specific reason for leveraging OnRequestStart over OnSessionStart?
    – Daniel
    Commented Apr 18, 2014 at 15:12
  • Basically, OnSessionStart is unreliable for a number of reasons (most of which are related to the web servers we support). OnRequestStart is solid, however. And it's easy to get the same functionality in OnRequestStart by simply checking if you need to do the work or not.
    – Peter Kjaer
    Commented Apr 22, 2014 at 8:04

2 Answers 2

Reset to default
3

The default configuration for the ADF session cookie does not set the Path value to '/'. Add the following to your cd_ambient_conf.xml to resolve it:

<Cookies><Cookie Type="Session" Name="TAFSessionId" Path="/" /></Cookies>

You can also choose to change the cookie name. I've used the default value in the example above.

Improve this answer
2
  • Art, this default value was indeed the reason we were getting such inconsistent results. We were ending up with multiple session ids at various paths depending on where the visitor would enter the site.
    – Daniel
    Commented May 7, 2014 at 18:21
  • The advice around SessionStart vs. RequestStart was also very valuable. It would seem that some of the default claims are also lost when the app servers session expires (session time stamp and session time).
    – Daniel
    Commented May 7, 2014 at 18:22
1

I've always wanted to get the bottom of this, I hope an answer is found. In the meantime I use the advice from peter above and use OnRequestStart and check if any of the variables i'm monitoring have changed.

In my implementation experience this is also a good way forward as it's common that a user will perform tasks that require that this information is updated on the fly.

thanks

Improve this answer
1
  • 2
    Technically, the Claim Store is stored in your web server's Session (whatever implementation it uses). So when that expires, a new session is created and your Claim Store is created anew. The complications come in when you still have an ADF session ID in your cookie. In that case, the ADF resumes the session by re-using the ID - but the OnSessionStart method is not called on the cartridges. So you end up with the same session ID but without your values. I think this is a defect but it hasn't been changed yet. So I just advocate using the other method as it's always clear what happens.
    – Peter Kjaer
    Commented Apr 22, 2014 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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