HTTPSession vs Client Context for data storage in AEM

Question

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.

joerghoh · Accepted Answer

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

smacdonald2008 · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded