Oauth2-proxy: Anchor in original URL when redirecting to login page then original page is lost

[desaintmartin]

Currently, if one wants to visit an URL https://something.com/path?param=value#my-anchor and oauth2-proxy redirects to to the login page, everything after the anchor is lost since it is a purely browser based concept.

Expected Behavior

1/ User visits https://something.com/path?param=value#my-anchor
2/ User gets redirected to login page, and successfully logins
3/ User gets redirected to https://something.com/path?param=value#my-anchor

Current Behavior

1/ User visits https://something.com/path?param=value#my-anchor
2/ User gets redirected to login page, and successfully logins
3/ User gets redirected to https://something.com/path?param=value

Possible Solution

I am not even sure if the problem is in oauth2-proxy (see environment: lost in nginx?). I can see the hash being given to the login page at my gitlab, but it then disappears.
Since this is a purely browser concept, I am not even sure it is doable

Your Environment

• oauth2-proxy <-> oidc connector with Dex <-> gitlab
• nginx-ingress with:

  annotations:
    nginx.ingress.kubernetes.io/auth-signin: 'https://my-sso.com/oauth2/start?rd=$escaped_request_uri'
    nginx.ingress.kubernetes.io/auth-url: 'http://my-internal-oauth2-url/oauth2/auth'
    nginx.ingress.kubernetes.io/configuration-snippet: |
      auth_request_set $name_upstream_1 $upstream_cookie_name_1;

      access_by_lua_block {
        if ngx.var.name_upstream_1 ~= "" then
          ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
        end
      }

• Version used: 5.1.0

[JoelSpeed]

I've looked into this before. Anchors aren't sent as part of an HTTP request and as such exist only in the browser. There is no way to fix this unfortunately (without a rewrite of the HTTP spec 😅).

[desaintmartin]

Thanks! This was my first analysis before seeing some code tied to hash in the HTML template.
Maybe we should clarify this somewhere in the documentation, as it is possibly an anti-pattern.

[JoelSpeed]

@desaintmartin Can you link me to the code you mean?

[desaintmartin]

https://github.com/oauth2-proxy/oauth2-proxy/pull/353 but it seems related to a potential anchor in the login page itself, not the original URL page.

[JoelSpeed]

Yeah you're correct, that's to do with the login page itself and not to do with the original page