Bug 1356903 - Using IE getting "Validation of CSRF security token failed" on POST requests
Summary: Using IE getting "Validation of CSRF security token failed" on POST requests
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: WebUI
Version: 2.5
Hardware: noarch
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Grant Gainey
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space28
TreeView+ depends on / blocked
 
Reported: 2016-07-15 09:05 UTC by Tobias Oertel
Modified: 2018-04-20 12:21 UTC (History)
5 users (show)

Fixed In Version:
Clone Of: 1223240
Environment:
Last Closed: 2017-10-27 15:11:51 UTC
Embargoed:


Attachments (Terms of Use)

Description Tobias Oertel 2016-07-15 09:05:01 UTC
Description of problem:
Bug #1223240 is still present in Spacewalk 2.5.

Additional info:
Found wrong paths in spacewalk.css in:
spacewalk-branding-2.5.3-1.el7.noarch
spacewalk-branding-2.4.6-1.el7.noarch

+++ This bug was initially created as a clone of Bug #1223240 +++

Description of problem:
Using Internet Explorer to access the WebUI I get an "Validation of CSRF security token failed" error page from tomcat everytime I want to submit a form with POST request.
The reason are wrong paths to some font files in spacewalk.css.
This problem was already discussed in the following thread on the mailing list: 
https://www.redhat.com/archives/spacewalk-list/2015-May/msg00053.html

Version-Release number of selected component (if applicable):
spacewalk-branding-2.3.25-1.el6.noarch

How reproducible:
Everytime.

Steps to Reproduce:
1. Use Internet Explorer for WebUI
2. Make changes in the User Detail Page, e.g. change the position
3. Click Update-button to save the changes

Actual results:
tomcat error page with "Validation of CSRF security token failed".

Expected results:
User details are updated.

Additional info:
httpd access-logs for IE session:
WINDOWS-IP - - [19/May/2015:17:41:10 +0200] "GET /rhn/groups/ListRemoveSystems.do?sgid=37 HTTP/1.1" 200 112035
WINDOWS-IP - - [19/May/2015:17:41:10 +0200] "GET /components/font-awesome/fonts/fontawesome-webfont.eot? HTTP/1.1" 200 7822
WINDOWS-IP - - [19/May/2015:17:41:11 +0200] "GET /components/font-awesome/fonts/fontawesome-webfont.woff?v=4.1.0 HTTP/1.1" 200 7821
WINDOWS-IP - - [19/May/2015:17:41:11 +0200] "GET /components/font-awesome/fonts/fontawesome-webfont.ttf?v=4.1.0 HTTP/1.1" 200 7818
WINDOWS-IP - - [19/May/2015:17:41:20 +0200] "POST /rhn/groups/ListRemoveSystems.do?sgid=37 HTTP/1.1" 403 1084

==> IE tries to load fonts in "/components/font-awesome/fonts/" but this is an invalid path, it should be "/fonts/font-awesome/fonts/". Instead the default „Page Not Found“ page is rendered, which generates a new csrf_token and therefore the following POST request gets an 403 because an old csrf_token is sent.

After changing the font paths in spacewalk.css IE is working as expected. 
The changes I made are in the attached diff file.

--- Additional comment from Tomáš Kašpárek on 2015-05-20 08:34:17 EDT ---

I've patched patternfly1 buildtime dependency for spacewalk-branding so it uses correct paths.

Spacewalk commits:
2b2ca7f03d82622870c59f7c1bc7da790bbf82f0
62c8d688d284338392d32ed177f0bb1c5a099625

--- Additional comment from Jan Dobes on 2015-10-08 09:26:42 EDT ---

Spacewalk 2.4 has been released.

Comment 1 Jan Dobes 2017-10-27 15:11:51 UTC
I remember I solved this problem in our build system before Spacewalk 2.7 release. There was a wrong configuration and updated patternfly1 was missing in RHEL 7 buildroot.


Note You need to log in before you can comment on or make changes to this bug.