Allow serving content with an SSL terminated proxy #732

Closed
mjallday opened this Issue Apr 9, 2014 · 18 comments

Comments

Projects
None yet
4 participants
@mjallday

mjallday commented Apr 9, 2014

Does anyone have experience with configuring rundeck to run behind an SSL terminated proxy? i've got a setup which is "request -> AWS ELB:443 (HTTPS) -> rundeck:4440 (HTTP)" my issue is that the urls that rundeck redirects to with http not https.

e.g. simulating a request coming from the ELB by way of curl with headers set:

curl localhost:80 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"

* About to connect() to localhost port 80 (#0)                             
*   Trying 127.0.0.1... connected                                          
> GET / HTTP/1.1                                                           
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.
brtmp/2.3                                                                  
> Accept: */*                                                              
> Host: foo.com                                                            
> X-Forwarded-Proto: https                                                 
>                                                                          
< HTTP/1.1 302 Found                                                       
< Server: nginx/1.1.19                                                     
< Date: Wed, 09 Apr 2014 23:12:44 GMT                                      
< Content-Length: 0                                                        
< Connection: keep-alive                                                   
< Set-Cookie: JSESSIONID=vanjv9camddn1s009aqzcyw62;Path=/                  
< Expires: Thu, 01 Jan 1970 00:00:00 GMT                                   
< Location: http://foo.com/user/login;jsessionid=vanjv9camddn1s009aqzcyw62 
< Access-Control-Allow-Headers: X-Requested-With, Content-Type             
< Access-Control-Allow-Credentials: true                                   

Note the Location header in the response is http://foo.com rather than https://foo.com

I've tried updating grails.serverURL, apparently this property is obsoleted and no longer used by grails, it instead inspects the HTTP headers which is working for the host but not for the protocol.

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 9, 2014

I've seen plenty of answers for grails that utilize the spring security framework e.g. http://dmitrijs.artjomenko.com/2013/11/traffic-redirection-to-https-in-grails.html

I'm not sure if this is good solution since it means including another dependency.

mjallday commented Apr 9, 2014

I've seen plenty of answers for grails that utilize the spring security framework e.g. http://dmitrijs.artjomenko.com/2013/11/traffic-redirection-to-https-in-grails.html

I'm not sure if this is good solution since it means including another dependency.

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 10, 2014

Member

hi, we dont use the spring security plugin (currently). So the grails.serverURL is the correct place to set that value. Rundeck does use the grails.serverURL to generate absolute URLS used in RSS feed and API calls and some HTTP 30x redirects. For links in HTML that aren't absolute, the client browser should resolve them using the requested protocol and hostname for the page.

Member

gschueler commented Apr 10, 2014

hi, we dont use the spring security plugin (currently). So the grails.serverURL is the correct place to set that value. Rundeck does use the grails.serverURL to generate absolute URLS used in RSS feed and API calls and some HTTP 30x redirects. For links in HTML that aren't absolute, the client browser should resolve them using the requested protocol and hostname for the page.

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 10, 2014

Member

I notice this in your response:

Server: nginx/1.1.19

Do you have another proxy in front of Rundeck?

Member

gschueler commented Apr 10, 2014

I notice this in your response:

Server: nginx/1.1.19

Do you have another proxy in front of Rundeck?

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 10, 2014

I've tried it three different ways:

  1. ELB in front of rundeck
  2. Nginx in front of rundeck
  3. Direct HTTP request to rundeck

I've also set the grails.serverURL as mentioned in the original message but it does not appear to have any effect.

rundeck is already respecting the hostname regardless of the serverURL value, just not the protocol.

In the grails documentation for serverURL it mentions

grails.serverURL - A string specifying the server URL portion of absolute links, including server name e.g. grails.serverURL="http://my.yourportal.com". See createLink. Also used by redirects.

I've tried it three different ways:

  1. ELB in front of rundeck
  2. Nginx in front of rundeck
  3. Direct HTTP request to rundeck

I've also set the grails.serverURL as mentioned in the original message but it does not appear to have any effect.

rundeck is already respecting the hostname regardless of the serverURL value, just not the protocol.

In the grails documentation for serverURL it mentions

grails.serverURL - A string specifying the server URL portion of absolute links, including server name e.g. grails.serverURL="http://my.yourportal.com". See createLink. Also used by redirects.

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 10, 2014

Member

are you restarting rundeck after changing that value?

what version of Rundeck?

Member

gschueler commented Apr 10, 2014

are you restarting rundeck after changing that value?

what version of Rundeck?

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 10, 2014

Yes and 2.0.3.

If you try running the curl command curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https" I believe you should be able to see the exact same behavior that I am seeing.

curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"

* About to connect() to localhost port 4440 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=1v3vdxcznmpco1qysmyhn48yqz;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: http://foo.com/user/login;jsessionid=1v3vdxcznmpco1qysmyhn48yqz
< Content-Length: 0
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact
* Closing connection #0

Yes and 2.0.3.

If you try running the curl command curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https" I believe you should be able to see the exact same behavior that I am seeing.

curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"

* About to connect() to localhost port 4440 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=1v3vdxcznmpco1qysmyhn48yqz;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: http://foo.com/user/login;jsessionid=1v3vdxcznmpco1qysmyhn48yqz
< Content-Length: 0
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact
* Closing connection #0
@mahmoudimus

This comment has been minimized.

Show comment
Hide comment
@mahmoudimus

mahmoudimus Apr 11, 2014

ping @gschueler - any more insight?

ping @gschueler - any more insight?

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 11, 2014

Member

hi, just tested your curl command and I'm seeing the same thing. I'd guess the Jetty server which contains the webapp is not honoring the X-Forwarded-Proto header. I.e. the redirect to the login page is done by Jetty before rundeck sees it...

I will have to look into how to configure Jetty to do that

Member

gschueler commented Apr 11, 2014

hi, just tested your curl command and I'm seeing the same thing. I'd guess the Jetty server which contains the webapp is not honoring the X-Forwarded-Proto header. I.e. the redirect to the login page is done by Jetty before rundeck sees it...

I will have to look into how to configure Jetty to do that

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 11, 2014

Member

ah, looks like Jetty has a Connector.setForwarded(true) you can call http://wiki.eclipse.org/Jetty/Tutorial/Apache#Configuring_mod_proxy_http

so perhaps it's simply a matter of enabling a "forwarded" flag that will enable that in jetty

Member

gschueler commented Apr 11, 2014

ah, looks like Jetty has a Connector.setForwarded(true) you can call http://wiki.eclipse.org/Jetty/Tutorial/Apache#Configuring_mod_proxy_http

so perhaps it's simply a matter of enabling a "forwarded" flag that will enable that in jetty

@gschueler gschueler added this to the 2.0.4 milestone Apr 11, 2014

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 11, 2014

Member

tested this, seems to work.

[~/devel/rundeck (maint-2.0.4)⚡] ➔ curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"
* Adding handle: conn: 0x7fdbd3004000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fdbd3004000) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 4440 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 4440 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=18rwgzrnodio61s0vms9qhpok9;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: https://foo.com/user/login;jsessionid=18rwgzrnodio61s0vms9qhpok9
< Content-Length: 0
* Server Jetty(7.6.0.v20120127) is not blacklisted
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact

I will add this to 2.0.4 which is due next week.

I think to enable it I will make it so you will have to start rundeck with a new jvm flag -Drundeck.jetty.connector.forwarded=true explicitly. (e.g. add it to /etc/rundeck/profile)

Member

gschueler commented Apr 11, 2014

tested this, seems to work.

[~/devel/rundeck (maint-2.0.4)⚡] ➔ curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"
* Adding handle: conn: 0x7fdbd3004000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fdbd3004000) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 4440 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 4440 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=18rwgzrnodio61s0vms9qhpok9;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: https://foo.com/user/login;jsessionid=18rwgzrnodio61s0vms9qhpok9
< Content-Length: 0
* Server Jetty(7.6.0.v20120127) is not blacklisted
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact

I will add this to 2.0.4 which is due next week.

I think to enable it I will make it so you will have to start rundeck with a new jvm flag -Drundeck.jetty.connector.forwarded=true explicitly. (e.g. add it to /etc/rundeck/profile)

@mjallday

This comment has been minimized.

Show comment
Hide comment

👍

gschueler added a commit that referenced this issue Apr 11, 2014

Enable SSL terminated proxy support in jetty #732
* use jvm prop -Drundeck.jetty.connector.forwarded=true
@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 18, 2014

@gschueler what kind of review does this need? I took a look and your pull-request looks syntacticly valid and sane. if there's anything beyond that i can do to help move this forward just let me know.

@gschueler what kind of review does this need? I took a look and your pull-request looks syntacticly valid and sane. if there's anything beyond that i can do to help move this forward just let me know.

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Apr 18, 2014

Member

@mjallday thanks, it's a reminder to me to test the behavior before we do the release. planning to release 2.0.4 today. If you want to test the feature on a snapshot build, i've uploaded them here https://bintray.com/gschueler/rundeck-maint-maven

Member

gschueler commented Apr 18, 2014

@mjallday thanks, it's a reminder to me to test the behavior before we do the release. planning to release 2.0.4 today. If you want to test the feature on a snapshot build, i've uploaded them here https://bintray.com/gschueler/rundeck-maint-maven

@gschueler gschueler removed the needs-review label Apr 18, 2014

@gschueler gschueler closed this Apr 18, 2014

@mahmoudimus

This comment has been minimized.

Show comment
Hide comment
@mahmoudimus

mahmoudimus Apr 19, 2014

@gschueler looks like you forgot 2 publish the debian 2 bintray?

@gschueler looks like you forgot 2 publish the debian 2 bintray?

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 21, 2014

Gentle push to @gschueler - We're still seeing 2.0.3 as the latest at bintray - https://bintray.com/rundeck/rundeck-deb

The yum repo there has been updated however.

Gentle push to @gschueler - We're still seeing 2.0.3 as the latest at bintray - https://bintray.com/rundeck/rundeck-deb

The yum repo there has been updated however.

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Apr 22, 2014

Confirmed this works for us

curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"

* About to connect() to localhost port 4440 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=xp5926biqt2bhzb7y0hoinj0;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: https://foo.com/user/login;jsessionid=xp5926biqt2bhzb7y0hoinj0
< Content-Length: 0
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact
* Closing connection #0

thanks @gschueler

Confirmed this works for us

curl localhost:4440 -v -H "Host: foo.com" -H "X-Forwarded-Proto: https"

* About to connect() to localhost port 4440 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Accept: */*
> Host: foo.com
> X-Forwarded-Proto: https
> 
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=xp5926biqt2bhzb7y0hoinj0;Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: https://foo.com/user/login;jsessionid=xp5926biqt2bhzb7y0hoinj0
< Content-Length: 0
< Server: Jetty(7.6.0.v20120127)
< 
* Connection #0 to host localhost left intact
* Closing connection #0

thanks @gschueler

mjallday pushed a commit to poise/rundeck that referenced this issue Apr 22, 2014

klamontagne added a commit to klamontagne/rundeck that referenced this issue Jan 21, 2015

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy. 

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054

klamontagne added a commit to klamontagne/rundeck that referenced this issue Jan 21, 2015

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy.

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054

pcross616 pushed a commit to sous-chefs/rundeck that referenced this issue Nov 15, 2015

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy.

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054


Former-commit-id: b7ed47d9d39b355cc6336fe8afcc7086bf963535 [formerly 9b5e91fa87da4daee2a90e2ef782eb8082d4332b] [formerly 0db75f2b07edb1747cd706dc41ea309d9bca73f1 [formerly 0cf49b9]]
Former-commit-id: 18c012d67fe5a68146773caee261a148830b90f1 [formerly 2c789700f45313434c011884e3843d44d9f38578]
Former-commit-id: 8773b1d4731b2671022ea3aef70e73d5db7db320

pcross616 pushed a commit to sous-chefs/rundeck that referenced this issue Nov 15, 2015

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy.

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054
@dandunckelman

This comment has been minimized.

Show comment
Hide comment
@dandunckelman

dandunckelman May 4, 2017

Contributor

Anyone do this with HAProxy? I'm kinda stuck getting it to work.

Contributor

dandunckelman commented May 4, 2017

Anyone do this with HAProxy? I'm kinda stuck getting it to work.

scottymarshall pushed a commit to scottymarshall/rundeck that referenced this issue Mar 9, 2018

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy.

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054


Former-commit-id: b7ed47d9d39b355cc6336fe8afcc7086bf963535 [formerly 9b5e91fa87da4daee2a90e2ef782eb8082d4332b] [formerly 0db75f2b07edb1747cd706dc41ea309d9bca73f1 [formerly 489be84 [formerly 0cf49b9]]]
Former-commit-id: 18c012d67fe5a68146773caee261a148830b90f1 [formerly 2c789700f45313434c011884e3843d44d9f38578]
Former-commit-id: 8773b1d4731b2671022ea3aef70e73d5db7db320
Former-commit-id: 9145da3

scottymarshall pushed a commit to scottymarshall/rundeck that referenced this issue Mar 9, 2018

Fix https redirects when using a reverse proxy
When using an SSL terminated reverse proxy, users are redirected to a http:// URL during login. Jetty intercepts the request and does not respect the X-Forwarded-Proto header sent by the proxy.

Add the workaround provided in rundeck/rundeck#732
Support added in Rundeck in this commit: rundeck/rundeck@f1cb054


Former-commit-id: 83b3d8e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment