Expand my Community achievements bar.

SOLVED

What is the bestway to use Httpsession in AEM

Avatar

Level 2

Hello,

I am working with a client having a legacy code base(AEM-5.6.1) and in this project HTTPSession is extensively used to hold user specific information(user objects).

So my question is :-

1. How safe it is to use HTTPsession to hold user information in AEM along with extensive JCRsession uses. 

2. We are facing one issue where the user session is being swiped with other users.
i.e -  user "A" logs in and he is able to sees some information of user "B" (this issue happens intermittently, there is no specific pattern to reproduce.
So any pointers on this issue and what would be the best way to hold user specific information/objects in AEM.

 

Regards

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

to 1) When you use HTTP sessions, it is very hard to cache the generated output, normally you cannot cache the HTML then. There are cases which really require this, but this has to be a deliberate and very conscious decision! It's a safe approach (which means that AEM fully supports HTTP sessions), but not a recommended one.

to 2) So it is a problem with the HTTP session and that the session are not correctly assigned to the right user? Are you using AEM 5.6.1 with the built-in servlet engine (aka CQSE) or are you running AEM on a different one (application server).

kind regards,
Jörg

View solution in original post

6 Replies

Avatar

Level 10
  1. HTTPsession are server side sessions and hence violate the sessionless principle of REST and therefore should be used with care. It is almost always possible to not use HTTPsession please validate & change your implementation accordingly.
  2. May be some of your aem component has not set seesion explicitly true or dispatcher caching issue & others deponds on implementation.

Avatar

Correct answer by
Employee Advisor

Hi,

to 1) When you use HTTP sessions, it is very hard to cache the generated output, normally you cannot cache the HTML then. There are cases which really require this, but this has to be a deliberate and very conscious decision! It's a safe approach (which means that AEM fully supports HTTP sessions), but not a recommended one.

to 2) So it is a problem with the HTTP session and that the session are not correctly assigned to the right user? Are you using AEM 5.6.1 with the built-in servlet engine (aka CQSE) or are you running AEM on a different one (application server).

kind regards,
Jörg

Avatar

Level 2

If you have enabled Httpsession then you cannot have caching enabled. Can you check, where you see content swapped, are these pages being cached?

Avatar

Level 2

The assets are being cached but there is no caching implemented for pages.

Avatar

Level 2

Thanks Jorg,

Please find the answer to your questions.

Ans - We are using AEM 5.6.1 with built in servlet engine, AEM is not hosted in any other Application server

My question here is:-

1.what is the reason behind  the session are not correctly assigned to the right users.

2. What is the best way to maintain user objects or any objects in aem?
(FOR e.g.- If we have to maintain one heavy object that contains all the user and site information until the time, user logged in to the website(like J2ee applications) and get required data from the heavy Object through out user navigation then what is the best way to do this - Can we leverage client context here or is their any other approach that we need to follow.  )

Avatar

Employee Advisor

Hi,

When the assignment user to session is not working (that means, it works most of the time, but not always) it looks like a bug to me. Please raise a Daycare issue about that.

Regarding your second question: So you are using the user session both as cache and as store to track user activity? That sounds you're applying the J2EE best practices here, which are not the same as AEM best practices ... and one of the best practices of AEM is: be RESTful and do not have a server state.

Client context is one solution, as it moves the state to the client (where it actually belongs).

Kind regards,
Jörg