sign_in template form input redirect value is not updating as expected.

[sreeharikmarar]

The use case for this change is, suppose oauth2_proxy is running on https://companydomain/dashboard , after successful authentication oauth2_proxy is not redirecting back to /dashboardwhere the request has started.

The reason for this behavior is redirect-url config option is not updating sign_in template "{{.Redirect}}" value as expected because of this check.

pull request for this fix had already raised but seems like its not merged yet.

Other option is to update the hidden field value of sign_in template input form with window.location.pathname so that after authentication, oauth2_proxy returns the request back to the same redirect url which mentioned in the form input hidden field rd.

[jehiah]

@sreeharikmarar can you include steps to reproduce the behaviour you are seeing, and logs that show the original request (to /dashboard in your example) and the value of rd hidden field on that page response?

[sreeharikmarar]

@jehiah Think about a use case where nginx proxy pass the request from http://companydomain/dashboard to oauth2_proxy as mentioned below.

  location /dashboard/ {
         proxy_pass http://127.0.0.1:4180;
         proxy_redirect / /dashboard/;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Scheme $scheme;
         proxy_connect_timeout 1;
         proxy_send_timeout 30;
         proxy_read_timeout 30;
  }

  location = /oauth2/auth {
      internal;
      proxy_pass http://127.0.0.1:4180;
  }

  location /oauth2/ {
       proxy_pass http://127.0.0.1:4180;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Scheme $scheme;
  }

First request /dashboard -> /

41.202.81.166 - - [30/Aug/2016:19:28:26 +0530] domain.in GET - "/" HTTP/1.0 "Mozilla/5.0
 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/52.0.2743.116 Safari/537.36" 403 2682 0.000

Second request

41.202.81.166 - - [30/Aug/2016:19:29:10 +0530] domain.in GET - "/oauth2/start?rd=%2F"
 HTTP/1.0 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/52.0.2743.116 Safari/537.36" 302 323 0.000

Third request after authentication

since the state is still / it fails to redirect back to /dashboard.

41.202.81.166 - - [30/Aug/2016:19:29:16 +0530] domain.in GET - "/oauth2/callback?
state=/&code=4/pSYFpNNUEo3hGlYth_OH2r-1GYwPNFQbVwH4iWtFW70" HTTP/1.0 "Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" 302 24 0.301

The modified script will allow application to encode the state in the fragment.

[jehiah]

@sreeharikmarar so your request was for /dashboard but you only have /dashboard/ mapped to oauth2_proxy. You hit a different rule in your nginx config that redirected you to /, so that's unrelated to oauth2_proxy completely. (Note you don't have oauth2_proxy logs for that request)

You should either a) pass / through to oauth2_proxy, b) update your config to pass /dashboard to oauth2_proxy or c) re-test with /dashboard/ which is configured to pass through to oauth2_proxy.

[sreeharikmarar]

@jehiah Sorry, The request was for /dashboard/ and i tested with the same. nginx conf was just a sample. In either case oauth2_proxy is not re-directing back to the url where the request has started. unless you modify the script to update the redirect path towindow.location.pathname

[sreeharikmarar]

updating the conf.

  location /dashboard {
         proxy_pass http://127.0.0.1:4180;
         proxy_redirect / /dashboard;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Scheme $scheme;
         proxy_connect_timeout 1;
         proxy_send_timeout 30;
         proxy_read_timeout 30;
  }

  location = /oauth2/auth {
      internal;
      proxy_pass http://127.0.0.1:4180;
  }

  location /oauth2/ {
       proxy_pass http://127.0.0.1:4180;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Scheme $scheme;
  }

Form element

[jehiah]

@sreeharikmarar the log you included shows the following line as the HTTP 403 response that you initiated sign in from. If you start login from / you should end back up there.

41.202.81.166 - - [30/Aug/2016:19:28:26 +0530] domain.in GET - "/" HTTP/1.0 "Mozilla/5.0
 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/52.0.2743.116 Safari/537.36" 403 2682 0.000

Can You include updated logs showing a HTTP 403 (aka sign in page) returned from oauth2_proxy for /dashboard/ and then the following log for /oauth2/start?..... when you initiate login?

Sorry for the back and forth, but i don't have clear logs that show what you have described yet.

[sreeharikmarar]

@jehiah Let me try to explain the whole flow again. Suppose the use case is like this, We have
nginx running on one machine which loads the whole portal on http://comanydomain, and oauth2_proxy is running on another machine where some other app is also running which needs to be authenticated using oauth2_proxy.

When we request for http://comanydomain/dashboard nginx proxy pass the request to second machine where the oauth2_proxy app is running and it receives the request url as a root url '/' since we have not provided any proxy-prefix option to be nested under.

I agree to your previous comment that when you start sign-in from'/' you should end up there after authentication which is right. But what if the request started fromhttp://comanydomain/dashboard and the URL received by oauth2_proxy is still '/'. As you mentioned, after authentication oauth2_proxy will redirect back to '/' which in this case will be http://companydomain/ and not http://companydomain/dashboard where the app which needs to be authenticated using oauth2_proxy is running.

I was trying to explain this use case that rd value in the sign in form should be set based on which url oauth2_proxy app is running and not based on root url. Else we should have other option field in the configuration file where we can provide this redirect-url value, so that when oauth2_proxy sign in page loads on a particular url, rd value gets updated by the desired redirect-url value as per the configuration.

[sreeharikmarar]

@jehiah any update?

[jehiah]

@sreeharikmarar I'm going to close this issue. oauth2_proxy does not support URL rewriting in your configuration because it can't be expected to accommodate request rewriting outside of it's control. If you set nginx to proxy a request for /dashboard unmodified to oauth2_proxy as /dashboard the sign in flow will work as intended.

When we request for http://comanydomain/dashboard nginx proxy pass the request to second machine where the oauth2_proxy app is running and it receives the request url as a root url '/'