Use case

Use cases

• An admin-side service or UI that:
  • lists pending interactive registrations
  • approves a subset based on an allow/deny list, or after human review
• Automation using a periodic job that approves known devices, while still using registrationId.

Description

Background

• Since the registrationId flow was introduced (replacing mkey-based approval for interactive registration), pending registrations are short‑lived and tracked in memory until approved (AuthURL follow-up).
• This decouples identity from machine keys and fixes multi-user/same-machine cases, which is great.

Problem today

• For interactive registrations there’s no way for an external controller to see “what’s pending” and act on it.
• The pending registrations live only in the in-memory registration cache:
• As a result, an external approval service cannot discover pending registrationIds to approve them, and polling the DB won’t help (not persisted).

Is exposing pending interactive registrations acceptable within headscale’s design?

Contribution

• I can write the design doc for this feature
• I can contribute this feature

How can it be implemented?

No response