-
DescriptionAfter updating the headplane, the OIDC login feature is not working. Server LogClient Respond{
"code": 500,
"error": {
"name": "Internal Server Error",
"description": "An unknown error occurred"
}
}config.yamloidc:
issuer: "https://auth.example.app"
client_id: ""
client_secret: ""
disable_api_key_login: true
token_endpoint_auth_method: "client_secret_post"
headscale_api_key: ""
redirect_uri: "https://ts.example.app/admin/oidc/callback"Headplane Version0.6.1 Headscale Version0.26.1 |
Beta Was this translation helpful? Give feedback.
Replies: 18 comments 7 replies
-
|
Honestly, this entirely boils down to the library that I use for OIDC and I'm not pleased with it either, I'll push this off for |
Beta Was this translation helpful? Give feedback.
-
|
Same here after update Pocket-ID OIDC stopped working, I reverted back to 0.6.0 and I could login again! |
Beta Was this translation helpful? Give feedback.
-
|
I hate to hijack this problem thread but it is related, mostly ;). |
Beta Was this translation helpful? Give feedback.
-
|
I don't get this, I'm using a Pocket ID instance for testing my OIDC work when I develop locally. The only things I can think of is if you are using PKCE or not and if the token endpoint authentication method is set correctly. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not using PKCE. The auth method is: "client_secret_post" (was basic) With 0.6.0 I get: 0.6.0 doesn't log anything, and next logs this: If it matters, I've tried Firefox and Chromium. Everything is Linux of one flavor or another. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I got it working with 0.6.0 using client_secret_post. |
Beta Was this translation helpful? Give feedback.
-
|
@gunu3371 @BobWs For the claim comparison problem, I'd suggest triple-checking the |
Beta Was this translation helpful? Give feedback.
-
|
Can you check if it works with |
Beta Was this translation helpful? Give feedback.
-
|
I'm using Authentik as an IdP and had the same issue. Upgrading to |
Beta Was this translation helpful? Give feedback.
-
the beta version doesn't work for me I keep ending in a loop when trying to login with Pocket-ID. When I revert back to version Portainer log with the beta installed: Portainer log when I revert back to version headplane config.yml headscale config.yml docker-compose.yml |
Beta Was this translation helpful? Give feedback.
-
|
Does not work. An NS_ERROR_REDIRECT_LOOP error occurs at Server Log |
Beta Was this translation helpful? Give feedback.
-
|
@BobWs I've had Pocket ID working in 0.6.1 and all beta versions, it is most likely configuration error due to enabling something like PKCE in Pocket ID settings. Please refer to https://headplane.net/features/sso and reconfigure your SSO provider correctly. |
Beta Was this translation helpful? Give feedback.
-
|
@gunu3371 you have not provided any kind of useful log or error, NS_ERROR implies a client side error in the browser signifying a redirect loop. I advise you to reconfigure your OIDC correctly, given that I test against Auth0 and can use it. See: https://headplane.net/features/sso |
Beta Was this translation helpful? Give feedback.
-
I'm sorry but I can seem to get it to work! I double check the config settings with the descriptions here headplane.net/features/sso but can't find anything that is different. I also disabled the PKCE in Pocket ID (which was working fine in version 0.6.0) still didn't help. Maybe you can tell me what is wrong with my config files, that's why I posted everything earlier above! For now version 0.6.0 works with Pocket ID so I will stay on that version for now until I found a working solution for the update! |
Beta Was this translation helpful? Give feedback.
-
|
@BobWs I've gone through each item in your headplane Assuming you've fixed that already, the only other thing I see is that your headplane container can't see the headscale container: You may have a permissions problem between the account starting the containers and ownership/permissions on One other note is that if you tried the 0.6.2 beta, the option for PKCE is now |
Beta Was this translation helpful? Give feedback.
-
The
permissions for both containers are set to
Is already disabled Still finding it strange the with version 0.6.0 everything is working fine but updating to version Maybe someone could share their working config files and docker-compose files which is working with versions |
Beta Was this translation helpful? Give feedback.
-
|
Scope is a space separated list, no commas. |
Beta Was this translation helpful? Give feedback.
-
|
Finally got it working with headplane config.yml Docker log: |
Beta Was this translation helpful? Give feedback.
-
|
Headplane needs access to |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
It's hard to help with these specific issues mostly because it's hard to reproduce these kind of errors. Can you check to make sure that |
Beta Was this translation helpful? Give feedback.
-
|
I’ll try again, but as I mentioned earlier in the thread, everything worked fine with version 0.6.0—there was no “docker‑sock” error in the logs, even after I upgraded to version 0.6.1. The error only appeared when I moved to version 0.6.2 beta. This isn’t the first container I’ve run that uses the Docker socket; I have several other containers sharing the socket and they all operate without issues. Moreover, if Headplane couldn’t communicate with the Headscale container, I wouldn’t be able to manage devices from the dashboard. Yet I can add, delete, and control devices just fine through the dashboard, even with the Docker‑sock warning. Am I misunderstanding something? |
Beta Was this translation helpful? Give feedback.
-
Headplane Bug Report & Configuration FixIssue 1: Docker Socket Permission Error in Headplane 0.6.2-beta.3Problem Description:When running Headplane in Docker with Docker socket integration enabled, the following error appears in logs: However, the application continues to run and basic functionality appears to work. Environment:
Root Cause Analysis:The issue stems from the Docker socket being mounted with read-only ( volumes:
- '/var/run/docker.sock:/var/run/docker.sock:ro'However, Headplane requires read-write access to the Docker socket to fully utilize Docker API functionality, including:
Evidence:
Solution:Remove the volumes:
# From:
# - '/var/run/docker.sock:/var/run/docker.sock:ro'
# To:
- '/var/run/docker.sock:/var/run/docker.sock'Impact:
Issue 2: Persistent OIDC user_storage_file Warning (Potential Bug)Problem Description:Headplane continuously logs this warning despite no The warning appears even when:
Environment:
Investigation Findings:
Root Cause Hypothesis:
Evidence of Potential Bug:
Request to Developers:
Additional Observations:Health Check Support:Headplane container lacks standard CLI tools (
Container Minimalism:The container uses a minimal Node.js runtime without shell or basic utilities, which:
Documentation Suggestions:
System Impact:
Report Prepared By: Community user experiencing these issues in production setup Note to Developers: Thank you for your work on Headplane! This feedback is provided to help improve the project. Both issues were encountered in a real-world deployment and resolved or understood through testing. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve resolved the authentication error encountered during the Headscale and Auth0 integration. Root Cause: The issue was a string mismatch in the issuer field. Auth0's standard issuer URI format includes a trailing slash (/), but my configuration was missing it. This caused the OIDC validation to fail because the issuer strings did not match exactly. Solution: Configuration Change: |
Beta Was this translation helpful? Give feedback.
I’ve resolved the authentication error encountered during the Headscale and Auth0 integration.
Root Cause: The issue was a string mismatch in the issuer field. Auth0's standard issuer URI format includes a trailing slash (/), but my configuration was missing it. This caused the OIDC validation to fail because the issuer strings did not match exactly.
Solution:
Adding the trailing slash to the issuer URI fixed the issue.
Configuration Change: