OIDC details seem to get URL encoded incorrectly.

[Snuupy]

trafficstars

Hi, I'm using Gitea as my OIDC provider which was working on a previous version (I don't exactly remember which one), but breaks on latest. I'm getting the following error after migrating to a config.yaml. Even if I generate a new OAuth2 Application key, I am always given this error similar to https://github.com/tale/headplane/issues/101 :

{"code":"OAUTH_RESPONSE_BODY_ERROR","error":{"name":"invalid_client","description":"cannot load client with client id: 'xxx%2Dxxx%2Dxxxx%2Dxxxx%2Dxxxxxxx'"}}

where the %2D are the dashes (-).

Is this an HTML encode/decode error? Or maybe it is this bug: https://github.com/juanfont/headscale/issues/2168 // https://github.com/tale/headplane/issues/117

I did try setting OIDC_CLIENT_SECRET_METHOD to client_secret_basic as suggested here https://github.com/tale/headplane/issues/89#issuecomment-2599598547 but that did not work either.

[tale]

Let me take a look, can you just give me an example Client ID of what you used?

[Snuupy]

Yes of course here is one I just generated by adding an Application in gitea

Client ID: a3a419b4-2fd4-43dc-af62-06c8f33f973c

[tale]

@Snuupy is this a reverse proxy error by any chance?

[Snuupy]

@Snuupy is this a reverse proxy error by any chance?

I don't think so, I didn't change my reverse proxy settings from the previous version. I'm using https://github.com/linuxserver/docker-swag

are you unable to reproduce?

here is my reverse proxy config:

# cat config/nginx/proxy-confs/headscale.subdomain.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;

    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name headscale.*;

    include /config/nginx/ssl.conf;

    client_body_timeout 5m;
    client_header_timeout 5m;

    location /admin {

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;


        set $upstream_app headplane;
        set $upstream_port 3000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_buffering off;
    }

    location / {
        
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;


        set $upstream_app2 headscale;
        set $upstream_port2 8080;
        set $upstream_proto2 http;
        proxy_pass $upstream_proto2://$upstream_app2:$upstream_port2;

        proxy_ignore_client_abort off;
        proxy_request_buffering off;
        proxy_buffering off;
        proxy_no_cache "always";
    }
}

[tale]

Nope I was able to only reproduce sometimes, which is why I guessed it could be a reverse proxy issue. I think technically the behavior my client does is correct, but not sure if an exception needs to be made in certain cases.

[tale]

Can you test the next tag please (ghcr.io/tale/headplane:next). Because I cannot reproduce it on that version and I literally set up Gitea with a reverse proxy to make sure it works.

[Snuupy]

on next I get

headplane        | Error: No route matches URL "/admin"
headplane        |     at getInternalRouterError (file:///app/build/server/assets/index-LoxfAbGR.js:7378:5)
headplane        |     at Object.query (file:///app/build/server/assets/index-LoxfAbGR.js:6357:19)
headplane        |     at handleDocumentRequest (file:///app/build/server/assets/index-LoxfAbGR.js:11065:40)
headplane        |     at requestHandler (file:///app/build/server/assets/index-LoxfAbGR.js:10980:24)
headplane        |     at file:///app/build/server/assets/index-LoxfAbGR.js:11390:14
headplane        |     at file:///app/build/server/assets/index-LoxfAbGR.js:11391:7
headplane        |     at async dispatch (file:///app/build/server/assets/index-LoxfAbGR.js:74:17)
headplane        |     at async dispatch (file:///app/build/server/assets/index-LoxfAbGR.js:74:17)
headplane        |     at async dispatch (file:///app/build/server/assets/index-LoxfAbGR.js:74:17)
headplane        |     at async file:///app/build/server/assets/index-LoxfAbGR.js:946:25
headplane        | <Router basename="/admin/"> is not able to match the URL "/admin" because it does not start with the basename, so the <Router> won't render anything.

o_o

[tale]

It is /admin/ with a trailing slash.

[Snuupy]

page loads on /admin/ but same error:

name | "invalid_client"
description | "cannot load client with client id: 'xxxxx%2Dxxxxx%2Dxxx%2Dxxxx%2Dxxxxxxxxxxxx'"

I will be switching to npmplus https://github.com/ZoeyVid/NPMplus soon™ so if you would prefer waiting for me to test that, that could be an option too

[tale]

If you try it without a reverse proxy are you able to reproduce the issue? When I attempted to reproduce, I tested Gitea both locally and behind a reverse proxy.

[tale]

Is there any update on this?

[Snuupy]

Sorry, haven't had time to test yet. I was planning on redoing my reverse proxy setup but have been bogged down on everything else going on. I will update when I've had more of a chance to test.