Forums de discussion

Passing Session variable not saving in session

Thomas Westley, modifié il y a 8 années.

Passing Session variable not saving in session

New Member Envoyer: 1 Date d'inscription: 21/10/15 Publications récentes
Hello,

I am trying to pass a session variable from Xtivia's XSF to a portlet. I am using Liferay Version 6.2.

Here is the Xtivia XSF code

@Route(uri="/change-users/{userid}", method="GET", authenticated=true)
public class ChangeUser extends AbstractAdelmanCommand implements IAuthorized,
		ICommand {

	/* (non-Javadoc)
	 * @see com.xtivia.xsf.core.commands.ICommand#execute(com.xtivia.xsf.core.commands.IContext)
	 */
	@Override
	public CommandResult execute(IContext ctx) throws Exception {
		// TODO Auto-generated method stub
		
		
		long userId = GetterUtil.getLong(ctx.find("userid"), -1);
		
		Long u = new Long(userId);
		
		HttpSession session = (HttpSession) ctx.find(ICommandKeys.HTTP_SESSION);
		
		session.setAttribute("LIFERAY_SHARED_EMULATED_USERID", u);
		
		return new CommandResult(true, "Successfully changed" + session.getAttribute("EMULATED_USERID").toString());
	}

}


And here is the code that I am using to retrieve the session object


long userId = currentUser.getUserId();  
		
		
		try
		{
			userId = Long.getLong(portletSession.getAttribute("LIFERAY_SHARED_EMULATED_USERID", PortletSession.APPLICATION_SCOPE).toString()).longValue();
		}
		catch(Exception ex)
		{
			
		}


Using the code above I always get the user id of the logged in user and not of the session variable.

Any help would be most appreciated.

Thanks in advance
thumbnail
David H Nebinger, modifié il y a 8 années.

RE: Passing Session variable not saving in session

Liferay Legend Publications: 14919 Date d'inscription: 02/09/06 Publications récentes
XSF runs in the portal's web application and is effectively using the HTTP session, not the portlet sessions. You won't be able to access it in the portlet session.

Besides, you're discarding the exception so you don't know why it's not pulling the value.

Also, the XSF security layer is injecting the current user ID into the context object, so that is the id of the logged in user anyway.