LiveUsers hack? :)

[Andew Jardine, módosítva 12 év-val korábban]

Hey Everyone.

I've spent several hours now trying to work this out but I think I am finally stuck -- so I am appealing to the Liferay Gods out there. Here is what I have to do/have done.

My solution has a requirement to allow users to act on behalf of another user who has delegated authority to them. The way we are doing this is through the liferay impersonation feature. That works great. Now, we are trying to limit users to a single session. We are trying to do this using the LiveUsers class and then iterating over the UserTracker objects returned in the map. We do this by creating a Post Login Action that performs this activity.

In the remainder of the application, detecting whether or not someone is impersonating someone is easy -- check the realUser object against the user object. Unfortunately, the LiveUsers only tracks the logged in user, and doesn't show anything to indicate that someone has performed an implied login using impersonation.

The only way I know to do this is to check the real user versus the (regular) user from the ThemeDisplay. I can get all the HTTP Sessions, for each of of the UserTracker elements, but the theme display doesn't appear to be part of the session.

Does anyone have any ideas how I might do this?

[jelmer kuperus, módosítva 12 év-val korábban]

ThemeDisplay is constructed by ServicePreAction (https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/events/ServicePreAction.java)

You can see that the real user is actually determined based on a value stored in the session. Eg :

Long realUserId = (Long)session.getAttribute(WebKeys.USER_ID);

if (realUserId != null) {
	if (user.getUserId() != realUserId.longValue()) {
		realUser = UserLocalServiceUtil.getUserById(
			realUserId.longValue());
	}
}

[Andew Jardine, módosítva 12 év-val korábban]

Jelmer,

Thanks for taking a crack. I think I follow what you are saying by I am not totally sure. I do understand that the REAL USER is in fact the credentials you entered to log into the system -- so as a result, the information I see in the LIVE USERS portlet is actually REAL USER information. Assume I have this though.


+ user #1 = Jack (id:1234)
+ user #2 = Jill (id:5678)
+ Jack has delegated authority to act on his behalf (impersonate him) to Jill.
+ Jill logs into the system
+ LiveUsers shows me that Jill has an active session (Jill is the real user so this is fine)
+ Jill impersonates Jack -- so now her REAL USER ID is the one for Jill (5678), but her USER ID is the one for Jack (1234)
+ Jack now tried to log in

Looping through the User Tracker, I need to be able to detect that although Jill is logged into the system, she is actually acting on behalf of Jack, thus not allowing him to log into the system. The user ID I get from the Session that I retrieve using HttpSession userSession = PortalSessionContext.get( tracker.getSessionId() ); is the one that shows Jill as logged in.

So how do I use her Session, to get the ThemeDisplay object to determine her active user id in place of her real user id? Or is there a way other than the ThemeDisplay to do this?

[Andew Jardine, módosítva 12 év-val korábban]

I've come to the conclusion (whether the correct conclusion or not) that it is not possible to achieve what I am trying to achieve using the LiveUsers functionality. As such, I am moving on. If anyone is interested in the approach I am investigating now, I'm trying to decide between one of the following.

Option #1: Service Builder
Use the service builder to create my own extension point where I basically do something similar to the LiveUsers, but include in my information whether or not the user is acting on behalf of someone, and store the user id of the user they are impersonating.

Option #2: Expando Attribute
Use the Expando bridge and add a impersonating_id value to the user model. When Jill impersonates Jack, Jack's impersonating_id is changed to contain Jill's id. In my post login hook I can check (when logging in as Jack) to see if there is a value set. If there is, then I can act accordingly. Storing the ID will allow me to retrieve the impersonating user to present the person logging in with information as to who is acting on their behalf.

We're already using the expando feature for some custom fields, so we'll probably go with Option #2.