You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If browser context path has changed a CSRF security error appears on edit this individual pages.
Direct web remoting library creates DWRSESSIONID cookie with path restricted to webapp_name, example: /vivo
So if public website has redirects from "/webapp_name" to "/", then
first request to /vivo/dwr/call/plaincall/PropertyDWR.getExistingProperties.dwr return 308 response code to
/dwr/call/plaincall/PropertyDWR.getExistingProperties.dwr
But on the second request DWRSESSIONID cookie is not present as it is valid only for /vivo context path which leads to the
the error message in browser "CSRF Security Error (see server log for details)"
So far I haven't found an option to override dwr context path.
DWR included in vivo as a library and configured in web.xml
But only available option overridePath doesn't solve the problem.
So the only workaround is to deploy vivo|vitro as tomcat ROOT application.
To Reproduce
Steps to reproduce the behavior:
Deploy vivo on tomcat with name vivo
Set sessionCookiePath="/" in tomcat context.xml
Create apache virtualhost with proxy to vivo on tomcat instance and configure proxy and redirects
RewriteRule ^/vivo/(.*) /$1 [R=308,L]
RewriteRule ^/vivo$ / [R=301,L]
ProxyPass ajp://127.0.0.1:8809/vivo/
4. Log in into VIVO and go to some individual page. Click edit this individual
Expected behavior
Page load without error messages and triples to edit present on the page
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
As a workaround we can avoid redirecting dwr specific requests.
To use replace vivo_app_name with your application name.
and internal_server_url with url to your internal server and port (usually 8009 port is used for ajp).
Apache2 configuration snippet. RewriteEngine on RewriteCond %{REQUEST_URI} !^/vivo_app_name/dwr/ RewriteRule ^/vivo_app_name/(.*) /$1 [R=308,L] <LocationMatch "/vivo_app_name/dwr/(.*)"> ProxyPass ajp://internal_server_url timeout=300 ProxyPassReverse ajp://internal_server_url </LocationMatch> <LocationMatch "^(?!/vivo_app_name/dwr)/[^/]*"> ProxyPass ajp://internal_server_url/vivo_app_name timeout=300 ProxyPassReverse ajp://internal_server_url/vivo_app_name </LocationMatch>
Session cookie path should be set to in tomcat context.xml
AJP connector should also be configured in tomcat server.xml
Example (substitute server_ip with ip address to listen on): <Connector protocol="AJP/1.3" address="server_ip" URIEncoding="UTF-8" secretRequired="false" port="8009" connectionTimeout="300000" redirectPort="8443" />
Also change context.xml in tomcat fix authorization issue
Describe the bug
If browser context path has changed a CSRF security error appears on edit this individual pages.
Direct web remoting library creates DWRSESSIONID cookie with path restricted to webapp_name, example: /vivo
So if public website has redirects from "/webapp_name" to "/", then
first request to /vivo/dwr/call/plaincall/PropertyDWR.getExistingProperties.dwr return 308 response code to
/dwr/call/plaincall/PropertyDWR.getExistingProperties.dwr
But on the second request DWRSESSIONID cookie is not present as it is valid only for /vivo context path which leads to the
the error message in browser "CSRF Security Error (see server log for details)"
So far I haven't found an option to override dwr context path.
DWR included in vivo as a library and configured in web.xml
But only available option overridePath doesn't solve the problem.
So the only workaround is to deploy vivo|vitro as tomcat ROOT application.
To Reproduce
Steps to reproduce the behavior:
RewriteRule ^/vivo/(.*) /$1 [R=308,L]
RewriteRule ^/vivo$ / [R=301,L]
Expected behavior
Page load without error messages and triples to edit present on the page
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: