RE: [go-cd] Issues with saving xml on secure url with reverse proxy

[chantryc]

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-cd@googlegroups.com  On Behalf Of Aravind SV
Sent: Tuesday, January 17, 2023 11:10 AM
To: go-cd@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.

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

From:   Chad Wilson
Subject: Re: [go-cd] Issues with saving xml on secure url with reverse proxy
To: go-cd@googlegroups.com  
Date: Wed, 18 Jan 2023 00:08:23 +0800

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

 

 

 

On Tue, Jan 17, 2023 at 10:32 PM Funkycybermonk mailto:chant...@gmail.com> > wrote:

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:

Re: [go-cd] Issues with saving xml on secure url with reverse proxy

[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](https://docs.gocd.org/current/installation/configure-reverse-proxy.html).

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"): 

Regards,
Aravind

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/m25yd5uly4.fsf%40arvindsv.com.

Re: [go-cd] Issues with saving xml on secure url with reverse proxy

[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




On Tue, Jan 17, 2023 at 10:32 PM Funkycybermonk  wrote:

> 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!
>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH96NS-z82SfcZLdhQQvarU4GeeAAqC_vPNRR%3D1dZTnRTA%40mail.gmail.com.

[go-cd] 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!

-- 
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+unsubscr...@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.