"Invalid authentication token" because of Liferay CSRF protection

[Alexey Kakunin, geändert vor 13 Jahren.]

Hi!

I'm porting JSPPortlet (now MVCPortlet) form Liferay 5 to Liferay 6.
In new version I'm using aui:form - but looks reason not in it.

I have form and this form submit some data into action. After pressing submit I receive error:

21:49:31,954 INFO  [PortalImpl:3496] Current URL /group/reseller1/orders?p_auth=QgchY5LR&p_p_id=aaa_WAR_bbbportlet&p_p_lifecycle=1&p_p_state=maximized&p_p_mode=view&_aaa_WAR_bbbportlet_javax.portlet.action=createOrder generates exception: Invalid authentication token
21:49:31,955 WARN  [PortalImpl:3502] com.liferay.portal.security.auth.PrincipalException: Invalid authentication token
com.liferay.portal.security.auth.PrincipalException: Invalid authentication token
	at com.liferay.portal.security.auth.SessionAuthToken.check(SessionAuthToken.java:58)
	at com.liferay.portal.security.auth.AuthTokenWrapper.check(AuthTokenWrapper.java:33)
	at com.liferay.portal.security.auth.AuthTokenUtil.check(AuthTokenUtil.java:31)
	at com.liferay.portal.action.LayoutAction.processPortletRequest(LayoutAction.java:721)
	at com.liferay.portal.action.LayoutAction.processLayout(LayoutAction.java:548)
	at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:217)

It is clear - to protect against CSRF Liferay generates token and then tried to compare token received in request with token stored in session.

As I can see in debugger - in my case it failed because tokens are different.
I did not found any information for developers how to control/use these tokens.
Should I do something additional in my portlet for make it working?

[Alexey Kakunin, geändert vor 13 Jahren.]

Really strange.
After logout/login problem is gone. Unfortunately I had no chance to check a little bit more deep why it happens while it was reproduced.

Probably some bug in 6.0.1

[Amos Fong, geändert vor 13 Jahren.]

There was a bug where plugins could not see the session token so it generated it own. Has been fixed (or will be) in latest 6.0.x release.

[Carlo Meneses, geändert vor 13 Jahren.]

I'm having the same problem with jmeter. Every time jmeter tries to submit any form it gets an invalid authentication token and the save/submit form doesn't push through. Can this csrf protection be disabled?

[Puj Z, geändert vor 13 Jahren.]

Hi Amos,

We are having the same problem (in 6.0.4). Has this "Invalid authentication token" issue been solved in 6.0.5?

Because of a bug in Liferay we cannot deploy our ext in 6.0.5 and have to use 6.0.4 for now.
If the problem is solved in 6.0.5 then we should think of a solution for our ext to migrate to 6.0.5. Otherwise we just wait for 6.0.6

[Jakub Liska, geändert vor 13 Jahren.]

I have this issue too. I'm using current trunk version and this happens when I'm uploading a file via the flash upload.js script ... I really don't know what to do with it... ISSUE

It happens no matter if auth.token.check.enabled is set to "false" ... I'm not sure whether the upload.js javascript upload is made only for struts actions.....

[Amos Fong, geändert vor 13 Jahren.]

Hi Jakub,

I'm able to upload in trunk ok, can you post your stacktrace in the jira ticket?

[Jakub Liska, geändert vor 13 Jahren.]

Hi Amos, have you tried to upload a file via the upload.js script ? Otherwise uploads work fine for me.... I don't like JS but it looks pretty straightforward. Don't know what's wrong. I attached the logs to the issue. Thank you

[Kim A Kunc, geändert vor 13 Jahren.]

Hi, I have the same exception using Liferay 6.0.5.

"com.liferay.portal.security.auth.PrincipalException: Invalid authentication token
at com.liferay.portal.security.auth.SessionAuthToken.check(SessionAuthToken.java:67)
at com.liferay.portal.security.auth.AuthTokenWrapper.check(AuthTokenWrapper.java:32)
at com.liferay.portal.security.auth.AuthTokenUtil.check(AuthTokenUtil.java:29)
"
The exception only occurs at times on a development server but I generally don't want token authentication for this portlet at all.

None of the changes I made to portlet-ext.properties or portlet.xml to ignore the token check seem to take any effect.

I tried:

(1)

<init-param>
 <name>check-auth-token</name>
 <value>false</value>
</init-param>

(2)
auth.token.ignore.actions=\myportlet/path

But my portlet allways produces a URL with p_auth param...

Is there a way to get a PortalURL without the p_auth Parameter ?

[Kim A Kunc, geändert vor 13 Jahren.]

I had a look at method addPortletAuthToken()
in com.liferay.portletPortletURLImpl

It seems that this method will create the auth token unless the property to generally use auth tokens is false in portal.properties...

protected void addPortletAuthToken(StringBundler sb, Key key) {
		if (!PropsValues.PORTLET_ADD_DEFAULT_RESOURCE_CHECK_ENABLED) {
			return;
		}

   ...

So how do you avoid having the token created ?

[Kim A Kunc, geändert vor 13 Jahren.]

The Exception only occurs if the portlet is used as "guest".
Are there specific properties in portal.properties to configure guest session handling ?
Could this be the problem ?

[Jakub Liska, geändert vor 13 Jahren.]

Hi Kim,

take a look at the issue here ... It seems Amos is looking at it. I'm still waiting until it is resolved, because both of the properties (auth.token.ignore.actions included) do not work for me and I can barely see through it. Javascript thing... Regards

[Jhansi Rani, geändert vor 12 Jahren.]

Hi,

set the following property in portal-ext.properties
auth.token.check.enabled=false

which disables p_Auth request attribute.

[Roberto Javier Aguirre, geändert vor 13 Jahren.]

Hi, please could you tell me, when this bug will be have a solution?

[Kim A Kunc, geändert vor 13 Jahren.]

I had this problem in another portlet when from data is sent to a Spring portlet.
My quick workaround for this, is currently overriding "SessionAuthToken" with ext plugin.

A better way is to implement your own class (see portal.properties -> auth.token.impl=com.liferay.portal.security.auth.SessionAuthToken)

Anyway I use the "isIgnoreAction()" method and return true for my spring portlets identified by ppid...

protected boolean isIgnoreAction(HttpServletRequest request) {
String ppid = ParamUtil.getString(request, "p_p_id");

String portletNamespace = PortalUtil.getPortletNamespace(ppid);

String strutsAction = ParamUtil.getString(
request, portletNamespace + "struts_action");

return isIgnoreAction(strutsAction);
}

[Corentin R, geändert vor 13 Jahren.]

Is there still no fix for this issue ?
I'm facing the same problem as I tryed to describe it there

But I'm not using any Struts or Spring Portlet only the classical MVCPortlet...

[Jason Chen, geändert vor 12 Jahren.]

any update on this or JIRA number related to this issue? I just debugged through version 6.0.5 and can confirm this issue is still there.
The tokens stored in the portal session are different from the one in the portlets/plugins. Any patch for this?

[Domingo Piña, geändert vor 12 Jahren.]

In LR 6.0.5 you can disable the checking for authentication token for specific portlets via the init parameter "check-auth-token" in portlet.xml (not used, seen in portal.properties)

In LR 6 EE SP1 you can put the following property into portal-ext.properties:

auth.token.ignore.portlets=portlet_name

for example:

auth.token.ignore.portlets=test_WAR_test

[Alvaro del Castillo, geändert vor 12 Jahren.]

Great, it works for me using "check-auth-token" in the portlet config:

<init-param>
            <name>check-auth-token</name>
            <value>false</value>
        </init-param>

I am not sure if this an important security feature, checking the auth token.

[R V, geändert vor 12 Jahren.]

could you please tell me the exact name of the file in which CHECK-AUTH-TOKEN change needs to be done in 6.0.5 CE. is it liferay-portlet.xml...

[Alexey Kakunin, geändert vor 12 Jahren.]

I was able to reproduce this problem in 6.0.6 CE (even it was "fixed" long time ago).
Hopefully I have ability to 100% reproduce the problem. Not sure - may be it is specific to some configuration or specific case.

In my case problem reproduced then session initialized (for example we are doing login) on specific page - this page has my portlet opened in maximized mode.
So - problem reprodcued only in case I'm doing login on this page - still need more time to investigate why only here.

I've added some more logs into com.liferay.portal.security.auth.SessionAuthToken class - responsible for authtoken generation.

and what I can see from logs:


first - tokenMap generated and placed twice into session with same id:

23:42:21,457 ERROR [SessionAuthToken:123] generate token map for session: DBC98B96EFF5C770205DC4AAB2E78607
23:42:21,464 ERROR [SessionAuthToken:124] session class: org.apache.catalina.session.StandardSessionFacade
23:42:21,537 ERROR [SessionAuthToken:123] generate token map for session: DBC98B96EFF5C770205DC4AAB2E78607
23:42:21,539 ERROR [SessionAuthToken:124] session class: com.liferay.util.servlet.SharedSessionWrapper

Sessions has same ID - but different implementation class:
first call comes somethere from theme - it is generated url to /my-places
It is used StandardSessionFacade (and StandardSession imlementation)

Second call goes from my portlet to generate some PortletURL. It is used SharedSesionWrapper.
I've checked in debug - SharedSession stored reference to StandardSession inside it - but it is different comparing to used in first call.

It has different set of attributes.


Then token for "PORTAL" is generated - for each map generated own token:

23:42:21,590 ERROR [SessionAuthToken:102] sessionID: DBC98B96EFF5C770205DC4AAB2E78607
23:42:21,591 ERROR [SessionAuthToken:103] token for PORTAL generated: Gi6dTEWh
23:42:21,592 ERROR [SessionAuthToken:104] sessionAuthenticationTokensMap: {11355_LAYOUT_showcase_WAR_shoppingportlet=Sz9l1Ecx, 11355_LAYOUT_shoppingcategories_WAR_shoppingportlet=fpE2eJIk}
23:42:22,487 ERROR [SessionAuthToken:102] sessionID: DBC98B96EFF5C770205DC4AAB2E78607
23:42:22,489 ERROR [SessionAuthToken:103] token for PORTAL generated: 4WqRsB7Q
23:42:22,497 ERROR [SessionAuthToken:104] sessionAuthenticationTokensMap: {11355_LAYOUT_86=7m8PWWht, 11355_LAYOUT_showcase_WAR_shoppingportlet=PfDyr3Kf, 11355_LAYOUT_1_WAR_chatportlet=Xggn5CfT}

You see - in both cases since different sessions an different tokenMaps was used - set of stored tokens are different.
As result, one token is used in URL, but different was stored in session and used later for validation.

For me it looks like set of concurrency problem - it looks like 2 requests called in parallel - one to render theme, second to render my portlet, And it happens - what both requests started to use different session - better say my portlet started to use wrong one. As result, wrong authToken was used to generate URLs, but later, then we need to perform check during calling actionURL - it was compared with stored in correct session - and I've got error.

Has anybody any ideas why wrong sharedSession object referenced to wrong StandardSession maybe generated? Probably somebody already met such problem?

[Tejas Purohit, geändert vor 12 Jahren.]

I am also facing this, My Case is:

I have configured Friendly URLs for my Portlet.

Friendly URL Configurations in liferay-portlet.xml

<friendly-url-mapper-class>
			com.liferay.portal.kernel.portlet.DefaultFriendlyURLMapper
</friendly-url-mapper-class>
<friendly-url-mapping>
			sample_portlet
</friendly-url-mapping>
<friendly-url-routes>
			sample/portlet/routes.xml
</friendly-url-routes>

sample/portlet/routes.xml

<routes>
    <!-- Login Action -->
    <route>
        <pattern>/login</pattern>
        <implicit-parameter name="p_p_lifecycle">1</implicit-parameter>
        <implicit-parameter name="javax.portlet.action">doLogin</implicit-parameter>
    </route>

    <!-- Logout Action -->
    <route>
        <pattern>/logout</pattern>
        <implicit-parameter name="p_p_lifecycle">1</implicit-parameter>
        <implicit-parameter name="javax.portlet.action">doLogout</implicit-parameter>
    </route>

    <!-- JSP Pages-->	
    <route>
        <pattern>/{jspPageName}</pattern>
        <generated-parameter name="jspPage">/{jspPageName}.jsp</generated-parameter>
    </route>
	
</routes>

URLS:

Friendly URLs for JSP files works great.
https://localhost:9443/web/mycommunity/home/-/sample_portlet/view - Works OK
https://localhost:9443/web/mycommunity/home/-/sample_portlet/help - Works OK


https://localhost:9443/web/mycommunity/home/-/sample_portlet/login - Thows Error
https://localhost:9443/web/mycommunity/home/-/sample_portlet/logout - Thows Error

On Screen Error: You do not have permission to access the requested resource.
Server Logs:

12:40:09,919 INFO  [PortalImpl:3948] Current URL /web/mycommunity/home/-/sample_portlet/login generates exception: Invalid authentication token
12:40:09,934 INFO  [PortalImpl:3967] com.liferay.portal.security.auth.PrincipalException: Invalid authentication token
com.liferay.portal.security.auth.PrincipalException: Invalid authentication token
	at com.liferay.portal.security.auth.SessionAuthToken.check(SessionAuthToken.java:60)
	at com.liferay.portal.security.auth.AuthTokenWrapper.check(AuthTokenWrapper.java:32)
	at com.liferay.portal.security.auth.AuthTokenUtil.check(AuthTokenUtil.java:29)
	at com.liferay.portal.action.LayoutAction.processPortletRequest(LayoutAction.java:756)
	at com.liferay.portal.action.LayoutAction.processLayout(LayoutAction.java:576)
	at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:232)
	at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
	at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
	at com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:154)
	at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
	at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
	at com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:520)
	at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:497)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Please Note: All the actions are working fine, they are only giving pain while accessing them via friendly URLS.

Please advice me workarounds for this problem. do any one had faced similar problem and solved it then please share your ideas. Also advice if I had made any mistakes in configurations of friendly URLs for MVC Portlet Actions.

Thanks,
Tejas

[Mary Mizrahi, geändert vor 12 Jahren.]

I have the same problem with the configuration pop up on my portlet. I added a setup page and for a while I had no problems. Then I added my own theme and I started getting the authentication token failure. Is this just a coincidence? Is there a fix for this issue yet?
The only fix that works for me is turning the auth token check off completely.