[Bug] Pre-auth keys "user" field returns the email. #996

Closed
opened 2025-12-29 02:27:12 +01:00 by adam · 0 comments
Owner

Originally created by @tale on GitHub (Apr 6, 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'm not entirely sure if this is intended behavior or a bug, but when requesting pre-auth keys via the API /api/v1/preauthkey?user=<user>, the user field on the returned keys have emails and not the user.name or a user object.

Example:

{
  "preAuthKeys": [
    {
      "user": "aarnavtale@icloud.com",
      "id": "2",
      "key": "[redacted]",
      "reusable": true,
      "ephemeral": false,
      "used": true,
      "expiration": "2025-07-05T19:00:37.730Z",
      "createdAt": "2025-04-06T19:00:37.840878704Z",
      "aclTags": []
    }
  ]
}

Expected Behavior

API docs aren't clear on this and I expect the response to either return the user.name since that is what we use to filter for pre-auth keys in the request (?user=<user.name>). Or even better, it should return the entire user object, exactly the same as how /api/v1/node does.

Steps To Reproduce

  1. Setup Headscale with OIDC
  2. Authenticate via OIDC (creating an OIDC user in the database)
  3. Generate a pre-auth key tied to the OIDC user
  4. Request the auth keys tied to the OIDC user via the API.

Environment

- OS: macOS Sequoia 15.3.2
- Headscale version: v0.25.1
- Tailscale version: 1.82.0

Runtime environment

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

Debug information

status.json
debug_netmap.json

Originally created by @tale on GitHub (Apr 6, 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'm not entirely sure if this is intended behavior or a bug, but when requesting pre-auth keys via the API `/api/v1/preauthkey?user=<user>`, the `user` field on the returned keys have emails and not the `user.name` or a user object. Example: ```json { "preAuthKeys": [ { "user": "aarnavtale@icloud.com", "id": "2", "key": "[redacted]", "reusable": true, "ephemeral": false, "used": true, "expiration": "2025-07-05T19:00:37.730Z", "createdAt": "2025-04-06T19:00:37.840878704Z", "aclTags": [] } ] } ``` ### Expected Behavior API docs aren't clear on this and I expect the response to either return the `user.name` since that is what we use to filter for pre-auth keys in the request (`?user=<user.name>`). Or even better, it should return the entire user object, exactly the same as how `/api/v1/node` does. ### Steps To Reproduce 1. Setup Headscale with OIDC 2. Authenticate via OIDC (creating an OIDC user in the database) 3. Generate a pre-auth key tied to the OIDC user 4. Request the auth keys tied to the OIDC user via the API. ### Environment ```markdown - OS: macOS Sequoia 15.3.2 - Headscale version: v0.25.1 - Tailscale version: 1.82.0 ``` ### Runtime environment - [ ] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information [status.json](https://github.com/user-attachments/files/19623076/status.json) [debug_netmap.json](https://github.com/user-attachments/files/19623075/debug_netmap.json)
adam added the bug label 2025-12-29 02:27:12 +01:00
adam closed this issue 2025-12-29 02:27:12 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#996