fix(pi-package-webui): support fixed remote PIN via PI_WEBUI_REMOTE_PIN env var#7
Open
buihongduc132 wants to merge 1 commit into
Open
Conversation
…IN env var generateRemotePin() now checks PI_WEBUI_REMOTE_PIN first; falls back to random PIN if unset or invalid (non-4-digit). Enables headless / supervised deployments where operator needs a stable PIN across restarts. - README: document PI_WEBUI_REMOTE_PIN in env var list - Test: remote-pin-env-harness covers valid pin, auth POST, wrong-pin rejection Default behavior (random PIN per start) preserved when env var unset.
There was a problem hiding this comment.
Pull request overview
Adds an operator-friendly option for pi-webui to use a stable Remote PIN in headless/supervised deployments by allowing the PIN to be supplied via an environment variable, while preserving the existing random-PIN default when unset/invalid.
Changes:
- Update
generateRemotePin()to preferPI_WEBUI_REMOTE_PINwhen it is exactly 4 digits; otherwise warn and fall back to a random PIN. - Document
PI_WEBUI_REMOTE_PINin thepi-package-webuiREADME. - Add a new harness test validating env-pinned Remote PIN behavior and auth success/failure paths.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| pi-package-webui/bin/pi-webui.mjs | Reads PI_WEBUI_REMOTE_PIN for Remote PIN generation with validation + fallback behavior. |
| pi-package-webui/README.md | Documents the new PI_WEBUI_REMOTE_PIN environment variable and its behavior. |
| pi-package-webui/tests/remote-pin-env-harness.test.mjs | Adds an integration-style harness test for fixed PIN startup and remote-auth POST outcomes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Owner
|
If we want to implement a fixed env var, PI_WEBUI_REMOTE_PIN (change var name) should instead be modeled as a fixed remote auth secret/token rather than a fixed 4-digit PIN. Suggested behavior:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
pi-webuigenerates a random 4-digit PIN on every server start (generateRemotePin()). Operators running headless / supervised deployments (e.g. behind a reverse proxy on a trusted LAN, or inside a Nomad/Kubernetes job) cannot know the PIN without querying the running alloc's logs. Restarting the alloc rotates the PIN, breaking bookmarks / saved sessions.Fix
generateRemotePin()now checksPI_WEBUI_REMOTE_PINfirst. If set and exactly 4 digits, it returns that value. If unset (or invalid), behavior is unchanged — a fresh random PIN is generated per server start.Why env var (not CLI flag / settings file)
PI_WEBUI_REMOTE_AUTH,PI_WEBUI_HOST,PI_WEBUI_PORT, etc.Changes
Validation
Backward compatibility
Default behavior (random PIN per start) is fully preserved when `PI_WEBUI_REMOTE_PIN` is unset. No existing test or behavior changes.
Security note
A fixed PIN reduces security versus random rotation; the README addition makes that explicit. This is opt-in only and is intended for trusted-LAN / supervised deployments where operator access to the PIN is required.