[Spacewalk-list] SP 2.3: Update user details issue

[Grant Gainey]

----- 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