The page isn’t redirecting properly

[clyang82]

I am using oauth-proxy in front of my service. I want to leverage the oauth-proxy capability to do authentication. Here is my configuration for oauth-proxy

    - --provider=openshift
    - --upstream=https://xxx.svc:8443
    - --upstream-ca=/etc/tls/ca/service-ca.crt
    - --https-address=:9443
    - --client-id=multicloudingress
    - --client-secret=xxxxxx
    - --pass-user-bearer-token=true
    - --pass-access-token=true
    - --scope=user:full
    - '-openshift-delegate-urls={"/": {"resource": "projects", "verb": "list"}}'
    - --skip-provider-button=true
    - --cookie-secure=true
    - --cookie-expire=12h0m0s
    - --cookie-refresh=8h0m0s
    - --tls-cert=/etc/tls/private/tls.crt
    - --tls-key=/etc/tls/private/tls.key
    - --cookie-secret=xxxx
    - --openshift-ca=/etc/pki/tls/cert.pem
    - --openshift-ca=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

I enabled auto-refresh for my page. I found that if the cookie is expired. sometimes, I can meet this below problem. first:

click to login

then Log in with OpenShift

I cannot go to my page. I have to close my browser and relogin. I am not sure if my usage is wrong or something wrong around oauth-proxy. Appreciate for any suggestions. I can append more details if needed. Thanks.

[clyang82]

@stlaz could you provide your comments or suggestions here? Thanks.

[clyang82]

append why the page is not redirecting properly. it is due to dead loop

[s-urbaniak]

Your nonce value stored in the _oauth2_proxy_csrf cookie does not match the nonce value returned from the oauth callback passed via the state request parameter. Make the value is correctly returned within the callback.

[clyang82]

@s-urbaniak Thanks for your reply. Could you elaborate more how to make the values is returned within the callback correctly? As I understand, the _oauth2_proxy_csrf cookies is set via SetCSRFCookie method. And the callback is also set by SetCSRFCookie method. https://github.com/openshift/oauth-proxy/blob/9ea1ebc89f721d3cd929f58c7ab9ed4273d3c493/oauthproxy.go#L610:L630 Where is my configuration wrong?

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci[bot]]

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/oauth-proxy/issues/232#issuecomment-1111781403): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[ibihim]

When the flag --skip-provider-button is set to true, you can't pass the target URI as a parameter. You will be always redirected to the upstream host of the proxy with an authenticated session on the root path /.

If you want to redirect to a relative path, you need to set --skip-provider-button to false. Or you need to make the upstream host able to handle a redirect to the root path /.

I understand your concern about this flow, but this is not a bug (this behavior is enforced on more than one place). You would need to raise a feature request.

[ibihim]

There is a CSRF token set. It prevents CSRF attacks. It is quite common to limit the life span of such tokens to a short period of time. This is not a bug.

[clyang82]

@ibihim Thanks for your response. We have switched to set --skip-provider-button to false.