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.