Miroslav Novák
Miroslav Novák

Reputation: 37

Liferay 7 - set shared session attribute in Authenticator class

I need to set a session in Authenticator class (key=auth.pipeline.pre) in Liferay. In this Authenticator class, I need to check credentials via another web service and set some attributes in session which should be shared with every other portlet.

I know this topic: Liferay 7 Shared Session Attributes

Problem is that I can't retrieve request (portletRequest as well) in Authenticator class.

I try the solution with PortalSessionThreadLocal like this:

String sharedKey = "LIFERAY_SHARED_" + key;
HttpSession session = PortalSessionThreadLocal.getHttpSession();
session.setAttribute(sharedKey, bean);

but I cant retrieve this session attribute in another portlet like this way:

key = "LIFERAY_SHARED_" + key;
HttpSession session = PortalSessionThreadLocal.getHttpSession();
Object bean = session.getAttribute(key);

Can you recommend me some sort of solution?

Upvotes: 1

Views: 564

Answers (3)

evaldeslacasa
evaldeslacasa

Reputation: 603

Avoid using session attributes.

Follow this post for more information: Session Storage is Evil

Storing things in the database is a better option. You can use Liferay's Service Builder to create your custom database table and easily perform operations with it in Java.

Upvotes: 0

VC1
VC1

Reputation: 1686

We had a similar use case. We used expandos/custom fields for persisting user information that retrieved with external web service calls during user authentication either in a custom auto login filter for SSO or a custom login portlet.

The expandos once stored can be retrieved via api calls in custom modules.

Example API call to save the expando:

user.getExpandoBridge().setAttribute("example", "value", false);

For more details you can look at this post: Expandos

Upvotes: 0

Victor
Victor

Reputation: 3688

It seems to me you have two issues to look for in your case, one is the scope as suggested in the post you linked.

And the second one is the fact that session attributes do not normally survive the authentication pipeline if you have phishing protection enabled.

Only whitelisted attributes survive, and those should be configured on your portal-ext.properties.

Upvotes: 1

Related Questions