starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-13 20:53:29 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] OIDC Register/Login Page Opens Twice #950

New Issue
Closed
opened 2025-12-29 02:26:36 +01:00 by adam · 8 comments
adam commented 2025-12-29 02:26:36 +01:00
Owner
Copy Link

Originally created by @GoodiesHQ on GitHub (Feb 23, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I noticed that, since upgrading to version 0.25, when I authenticate to my OIDC provider, it will open the login page with the /register/... URL twice. The first time, it redirects me to my OIDC provider as expected, and then successfully authenticating results in a page which shows:

Image

And then immediately afterwards, a new /register/... URL opens again (different identifier than the previous one) which redirects me to my OIDC provider for a second time. Another successfully authentication is required, which then shows the message:

Image

Only the first page is required. If I simply close the second page, it will work just fine. The second page seems to be fully redundant.

Expected Behavior

It's expected that only one register URL should be opened during the first authentication, and then one URL should open for re-authentication. Instead, I'm getting both "authenticated" and "re-authenticated" messages for both the first and subsequent authentications.

I opened this bug report because it is:

  1. Confusing to my users, and
  2. If the public domain is part of split-brain DNS with the internal domain, it can cause a "network changed" error message.

Steps To Reproduce

  1. Use HeadScale version 0.25
  2. Set up an OIDC provider

Environment

- OS: Linux (Docker image)
- Headscale version: 0.25.0
- Tailscale version: 1.80.0/1.80.2

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Anything else?

No response

Originally created by @GoodiesHQ on GitHub (Feb 23, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior I noticed that, since upgrading to version 0.25, when I authenticate to my OIDC provider, it will open the login page with the `/register/...` URL twice. The first time, it redirects me to my OIDC provider as expected, and then successfully authenticating results in a page which shows: ![Image](https://github.com/user-attachments/assets/651ba03d-da4b-4d1b-9717-c6c2d338aea3) And then immediately afterwards, a new `/register/...` URL opens again (different identifier than the previous one) which redirects me to my OIDC provider for a second time. Another successfully authentication is required, which then shows the message: ![Image](https://github.com/user-attachments/assets/d9792c03-d2e5-48fa-a8b8-b16bf37d5710) Only the first page is required. If I simply close the second page, it will work just fine. The second page seems to be fully redundant. ### Expected Behavior It's expected that only one register URL should be opened during the first authentication, and then one URL should open for re-authentication. Instead, I'm getting both "authenticated" and "re-authenticated" messages for both the first and subsequent authentications. I opened this bug report because it is: 1) Confusing to my users, and 2) If the public domain is part of split-brain DNS with the internal domain, it can cause a "network changed" error message. ### Steps To Reproduce 1. Use HeadScale version 0.25 2. Set up an OIDC provider ### Environment ```markdown - OS: Linux (Docker image) - Headscale version: 0.25.0 - Tailscale version: 1.80.0/1.80.2 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Anything else? _No response_
adam added the bug label 2025-12-29 02:26:36 +01:00
adam closed this issue 2025-12-29 02:26:37 +01:00
adam commented 2025-12-29 02:26:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 23, 2025):

Does it seem like the second register url is opened by the Client in the cli/UI or by a redirect from "Signed in via your OIDC provider" page?

I am trying to figure out how I can replicate this in a test.

@kradalby commented on GitHub (Feb 23, 2025): Does it seem like the second register url is opened by the Client in the cli/UI or by a redirect from "Signed in via your OIDC provider" page? I am trying to figure out how I can replicate this in a test.
adam commented 2025-12-29 02:26:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 23, 2025):

Is this happening in both GUI and CLI clients?

@kradalby commented on GitHub (Feb 23, 2025): Is this happening in both GUI and CLI clients?
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@GoodiesHQ commented on GitHub (Feb 23, 2025):

@kradalby good question. Until now, I only tested it using the GUI. Upon first registration and then manually expiring the node through the API and getting the popup:

Image

Using the CLI I can confirm that this command brought the same behavior, and it does in fact show both URLs in the terminal:

C:\>tailscale up --login-server=https://headscale.example.com --reset --unattended --accept-dns --accept-routes

To authenticate, visit:

        https://headscale.example.com/register/3oYCOZYA2zZmGB4PQ7aHBaMi


To authenticate, visit:

        https://headscale.example.com/register/dv1l2k5FackOYl-7-V3mSd_E

Success.
@GoodiesHQ commented on GitHub (Feb 23, 2025): @kradalby good question. Until now, I only tested it using the GUI. Upon first registration and then manually expiring the node through the API and getting the popup: ![Image](https://github.com/user-attachments/assets/4439cda7-677b-490f-b771-ab9e83fe87a4) Using the CLI I can confirm that this command brought the same behavior, and it does in fact show both URLs in the terminal: ``` C:\>tailscale up --login-server=https://headscale.example.com --reset --unattended --accept-dns --accept-routes To authenticate, visit: https://headscale.example.com/register/3oYCOZYA2zZmGB4PQ7aHBaMi To authenticate, visit: https://headscale.example.com/register/dv1l2k5FackOYl-7-V3mSd_E Success. ```
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@GoodiesHQ commented on GitHub (Feb 23, 2025):

In fact, I can even confirm that the second URL and the "Success." message gets printed even before the second URL has even loaded in my browser. I can freely close the second URL and it will still successfully log me in and print Success.

For what it's worth, I'm using Micrsoft 365/Entra as my IdP.

@GoodiesHQ commented on GitHub (Feb 23, 2025): In fact, I can even confirm that the second URL and the "Success." message gets printed even before the second URL has even loaded in my browser. I can freely close the second URL and it will still successfully log me in and print Success. For what it's worth, I'm using Micrsoft 365/Entra as my IdP.
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@oneingan commented on GitHub (Feb 24, 2025):

Same behavior for me with Entra IdP

@oneingan commented on GitHub (Feb 24, 2025): Same behavior for me with Entra IdP
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 24, 2025):

I wondered if this was happening in the tests and they passed because we just took the first URL and ignored the second, so I hardened that over in https://github.com/juanfont/headscale/pull/2445, but it doesnt seem like it is the case.

I am unable to reproduce it locally with our test infra, I wonder if it applies to other IdPs or if it is a Entra thing.

@kradalby commented on GitHub (Feb 24, 2025): I wondered if this was happening in the tests and they passed because we just took the first URL and ignored the second, so I hardened that over in https://github.com/juanfont/headscale/pull/2445, but it doesnt seem like it is the case. I am unable to reproduce it locally with our test infra, I wonder if it applies to other IdPs or if it is a Entra thing.
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Feb 24, 2025):

I am unable to reproduce it locally with our test infra, I wonder if it applies to other IdPs or if it is a Entra thing.

I've seen this with Keycloak, too. At first, there is only one URL visible. As soon as the login with Keycloak is successful, the second link is printed.

@nblock commented on GitHub (Feb 24, 2025): > I am unable to reproduce it locally with our test infra, I wonder if it applies to other IdPs or if it is a Entra thing. I've seen this with Keycloak, too. At first, there is only one URL visible. As soon as the login with Keycloak is successful, the second link is printed.
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@GoodiesHQ commented on GitHub (Feb 26, 2025):

I can confirm that this is fixed! Thank you @kradalby :D

@GoodiesHQ commented on GitHub (Feb 26, 2025): I can confirm that this is fixed! Thank you @kradalby :D
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#950
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?