Issues with saving xml on secure url with reverse proxy

[Funkycybermonk]

Hello!

I thought I had posted this and apparently didn't finish it. If there is a duplicate, apologies, I couldn't find it today.

After upgrading to 22.3 and setting up the IIS reverse proxy, I can do 99% of things, but there are a few issues such as editing the xml file that will throw an error when saving unless I change back to http/8153. In the logs I see an error that the http origin header didn't match the request.base_url along with the following lines:

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
 
actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:211:in `handle_unverified_request'
actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:243:in `handle_unverified_request'
actionpack (6.1.7) lib/action_controller/metal/request_forgery_protection.rb:238:in `verify_authenticity_token'

I'm not sure how to resolve the issue since everything generally works. I can do my updates over 8153 but it seems a little backwards to have to authenticate on an unsecure channel to make a change that I'm not trusted to make because I might be forging the token. 

Any ideas on how I can get around this? I'd think it was the reverse proxy but it all works properly outside this, as far as I can tell. And I'm doing the reverse proxy straight out of the Microsoft setup instructions/recommendations so nothing fancy there. 

Thanks!

[Chad Wilson]

Hiya

Not 100% sure if relevant, but is your Secure Site URL set correctly in Admin > Server Configuration?

With that limited description it sounds like perhaps your browser is trying to make cross-origin requests, e.g sending a request to https:// from something on http:// (or vice versa) which shouldn't really happen - especially if you are allowing both to work. On that theory, if you temporarily block http:// .. 8153 access entirely you might be able to find more easily where that problem is by seeing which resources/pages/API calls fail within your browser because they are somehow linking to a non-HTTPS URL or something like that.

It's also possible that the reverse proxy is doing something to the Origin headers, but I have not touched IIS for a very long time, and never used it in a reverse proxy mode, so have no specific insight there - and to me doesn't seem to explain the CSRF token errors. It also could be something not working as intended within GoCD.

Other than that, please try and share

• more specific details/steps of what you are doing to replicate the problem; whether you have tried in incognito/private mode and have the same outcome - that type of thing
  
• which specific actions/UI interactions are leading to the error (other than admin > config xml) - "a few issues" isn't very specific here. If the outcome/error is the same, we should try and establish a pattern as to which things are affected.
  
• please share exact and full error logs/traces, rather than partial pieces or descriptions. I think there should be a much larger log than this including the request details; with which you can partially redact anything sensitive.
• what changed between when it worked and when it didn't work? It's not clear whether it was a GoCD Server version upgrade or the introduction of the reverse proxy.
  

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/8c5c3abc-ef8d-4e56-9900-79773be9627fn%40googlegroups.com.

[Aravind SV]

Hello,

It’s also possible that the reverse proxy is doing something to the Origin headers, but I have not touched IIS for a very long time, and never used it in a reverse proxy mode, so have no specific insight there - and to me doesn’t seem to explain the CSRF token errors. It also could be something not working as intended within GoCD.

I think it is related to the reverse proxy setup. I’ve seen this happen when setups ignore the “X-Forwarded-For” header setup shown in the documentation.

How it ends up being related to CSRF tokens seems to be:

1. Server sends a response with a session ID in the cookie, along with a CSRF token to be sent back with the form response.
   
2. Due to the misconfiguration (could be secure site URL as you said), the cookie doesn’t get set / sent back with the form response.
   
3. Then, when the server tries to verify that the CSRF token sent back matches the one expected for the session, it doesn’t work, since the session won’t be the old session from point 1 above.
   

Something like that. I could be mistaken. Related issue which reminded me of this (no resolutions mentioned there, unfortunately, apart from “proxy configuration was the issue”): https://github.com/gocd/gocd/issues/5296

Regards,
Aravind

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH96NS-z82SfcZLdhQQvarU4GeeAAqC_vPNRR%3D1dZTnRTA%40mail.gmail.com.

[chan...@gmail.com]

Hello!

 

This helped me find the correct setting for my situation, although I don’t know if it’s a universal fix since I have a dedicated IIS install for the reverse proxies. I couldn’t find a way to get the reverse proxy itself to work properly but running the below command tells the ARR module to preserve the host headers instead of rewriting them.:

 

The command was:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true /commit:apphost

 

Everything else I had tried just broke the proxy entirely.

 

Thanks for the help and this can be considered closed.

 

Thanks!

 

From: go...@googlegroups.com <go...@googlegroups.com> On Behalf Of Aravind SV
Sent: Tuesday, January 17, 2023 11:10 AM
To: go...@googlegroups.com
Subject: Re: [go-cd] Issues with saving xml on secure url with reverse proxy

 

Hello,

It’s also possible that the reverse proxy is doing something to the Origin headers, but I have not touched IIS for a very long time, and never used it in a reverse proxy mode, so have no specific insight there - and to me doesn’t seem to explain the CSRF token errors. It also could be something not working as intended within GoCD.

I think it is related to the reverse proxy setup. I’ve seen this happen when setups ignore the “X-Forwarded-For” header setup shown in the documentation.

How it ends up being related to CSRF tokens seems to be:

1.    Server sends a response with a session ID in the cookie, along with a CSRF token to be sent back with the form response.

2.    Due to the misconfiguration (could be secure site URL as you said), the cookie doesn’t get set / sent back with the form response.

3.    Then, when the server tries to verify that the CSRF token sent back matches the one expected for the session, it doesn’t work, since the session won’t be the old session from point 1 above.

--
You received this message because you are subscribed to a topic in the Google Groups "go-cd" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/go-cd/NLBIV_xuRvE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/m25yd5uly4.fsf%40arvindsv.com.