----- Original Message ----- > Hello Grant, > > > > So - the question is, what is it about your setup, that causes the > > csrf_token value on the rendered web-page, to not-match the CSRF token > > stored in your login-session. I can think of ways to make that happen - > > but they would all break everyone's pages everywhere, every single time. I > > am having no luck finding a path through the code that would result in > > > > * session.token != page.token, and > > * your login-session still valid > > > > and only for *some*pages/actions. Ugh. > > I did some more testing and I have only problems with forms using > method=„POST“. For example the search form in the upper right corner, which > uses method=„GET“, is working fine with IE.
Yes - CSRF is only tested on POST. > > If you use Firefox or Chrome against your SW instance, is the problem still > > reproducible? > > Every other Browser I tested with, everything is OK: > Chrome 42.0.2311.135 (64-bit) on Mac > Chrome 40.0.2214.115 on Windows > Firefox 37.0.1 on Windows and Mac > Safari 8.0.6 on Mac "Only fails in IE" - wow, there's a surprise. I don't think I can adequately express my true feelings towards IE sometimes. :( > > Does the behavior change in IE if you change to/from compatibility-mode? > No, no change. > But now it gets weirder: /me cringes > I had a look into the browser built-in developer tools to check if the > correct csrf_token is sent. As far as I can see, all my browsers send the > right token in the POST-request. At least it is the same as in the HTML > sourcecode. > BUT when I use the developer tools within Safari on my Mac, I get the same > error as with IE. When I close the developer tools, then click on a > different tab to get a new csrf_token, then everything is working again. All > during the same session. Well, that's a hint, at least. When I can get my hands on Windows again, I'll see if I can reproduce that way. > Is it perhaps possible that there is some javascript which triggers a change > of the csrf_token after the HTML is sent to the browser? Depending on the > timing of the browser-engine? The rhn:csrf tag is filled in server-side as part of the server preparing the HTML to be sent to the client, it's not something that gets touched client-side. I can't imagine that IE's dev-tools are magically changing things - but it sure does feel like that. Ugh. > As a side note: Some forms contain the csrf_token twice (with the same value) > in the POST data, but this is the case with every browser, so I don’t think > this is a problem at all. Yeah, I recall fixing a few JSPs that had the tag in two places - clearly, I didn't find them all. It's not harmful, just...untidy. If you keep poking at this, let me know what you find; I'll do the same. In the meantime, 'turn off dev-tools, or use a browser that doesn't hate all of us' is my suggested workaround :) G -- Grant Gainey Principal Software Engineer, Red Hat Satellite _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
