Expand my Community achievements bar.

SOLVED

HTTPSession vs Client Context for data storage in AEM

Avatar

Level 3

For our current project implementation, we are storing response data from the WebService(SOAP and REST) in HTTPSession object and making use of it when ever necessary in both Java and UI layer. The data stored in the HTTPSession object is complex in Nature for example Customer(which has all the personal information), Details( which has all the details of the search). So the plan is to replace entire HTTPSession implementation of storing data to Local Storage(Browser Level). So the idea is to use the Client Context API provided by AEM and inject the data to Local Storage. 

Problems in Using Client Context

Problem 1: 
To store all the HTTP Session variables in the Client Context we have to convert every object in to String because Local storage can store only String variable. So there will be so many intermediate parsing steps to be achieved.

Problem 2:
For every request this data has to be sent to the server to recognize client data. If there is any update in  the data for example some search details, this data should be sent back to the client browser from the server then update the existing Local Storage object. For each subsequent request this data has to be passed to the server. The main concern here is when ever data gets updated there should be a response from the server to the client. This data will be used for the later WebService calls. This will increase the request and response hits form client to the server and latency will be a huge concern.

Problem 3:
To my understanding sensitive information like user address/phone number shouldn't be stored in the Local Storage.

To my understanding about Client Context:

Its AEM JavaScript API which is mainly meant to achieve Web Analytics's and Targeting. So tweaking this to mimic HTTPSession is a question for me.

Please suggest the best approach. Thanks in advance.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

It doesn't make sense to replace the server-side httpsession by a local-storage implementation at all costs. You cannot do it, when any malicious change on these stored data breaks your processes. It's also not a good idea if you need to constantly sync the data from the server to the localstorage and vice versa. In that case a server-side session is always easier to manage.

I would prefer the localstorage, if you store only per-session information, which is not sensitive at all. Personal information belong to a persistent store and not into a session (except for caching reasons).

You should provide more information on your specific usecase, so we can give you more and better advice.

kind regards,
Jörg

View solution in original post

3 Replies

Avatar

Level 10

You said "For our current project implementation, we are storing response data from the WebService"

Do you only want the data during the session - or longer term? I am trying to get an idea of your use case. Client Context may not be the best place to store return data from a SOAP call. 

Kalyan- you contributed the Sling Model artilce? Why not use a Sling Model and make use of that to store web service data. That way - you can perform CRUD operations on the WS data. 

Avatar

Level 3

All the data is required only for that particular session. No need to persist the data for future.

Avatar

Correct answer by
Employee Advisor

It doesn't make sense to replace the server-side httpsession by a local-storage implementation at all costs. You cannot do it, when any malicious change on these stored data breaks your processes. It's also not a good idea if you need to constantly sync the data from the server to the localstorage and vice versa. In that case a server-side session is always easier to manage.

I would prefer the localstorage, if you store only per-session information, which is not sensitive at all. Personal information belong to a persistent store and not into a session (except for caching reasons).

You should provide more information on your specific usecase, so we can give you more and better advice.

kind regards,
Jörg