docs: document password route protection#866
Conversation
The route-protect page only covered OIDC; password protection existed in the CLI but was undocumented. Add a Password Protection section covering provider setup, the login flow, password rotation, and default-route support, and reframe the page intro around both auth modes.
📝 WalkthroughWalkthroughThe route protection guide now describes route protection as supporting OIDC or shared-password login. It rewrites the authentication, trust model, and claim-mapping sections, updates provider examples for Google, GitLab, and Keycloak, and adds a password protection section covering provider setup, session cookies, logout, password rotation, and default-route use. It also renames provider management guidance and documents that removing a provider attached to routes requires Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/docs/route-protect.md`:
- Around line 206-208: Clarify the `route protect` docs so `--claim-header` is
not described as always ignored for password providers: the normal CLI path
warns and drops it, but the JSON input path rejects it. Update the wording in
the route-protect documentation to reflect both behaviors, using the `route
protect` command and `--claim-header` as the key references so users understand
the CLI-versus-JSON distinction.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: aa9c6bdc-470a-4275-bff1-2df9ea7389b8
📒 Files selected for processing (1)
docs/docs/route-protect.md
| `route protect` figures out on its own whether the named provider is OIDC or password, so the command is the same for both. That's all there is to it. Unauthenticated requests to `staging.example.com` now get a login form, and anyone who enters the right password is let through. | ||
|
|
||
| `--claim-header` has nothing to map for a password provider (there are no JWT claims), so it's ignored if you pass it. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify --claim-header behavior for password providers.
It is not always just "ignored": the normal CLI path warns and drops it, but JSON input rejects it. The docs should call out that distinction so users don't rely on the wrong behavior.
📝 Suggested wording
-`--claim-header` has nothing to map for a password provider (there are no JWT claims), so it's ignored if you pass it.
+`--claim-header` has nothing to map for a password provider (there are no JWT claims), so the normal CLI flow ignores it with a warning; JSON input rejects it.Based on cli/commands/route_protect.go:160-180.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| `route protect` figures out on its own whether the named provider is OIDC or password, so the command is the same for both. That's all there is to it. Unauthenticated requests to `staging.example.com` now get a login form, and anyone who enters the right password is let through. | |
| `--claim-header` has nothing to map for a password provider (there are no JWT claims), so it's ignored if you pass it. | |
| `route protect` figures out on its own whether the named provider is OIDC or password, so the command is the same for both. That's all there is to it. Unauthenticated requests to `staging.example.com` now get a login form, and anyone who enters the right password is let through. | |
| `--claim-header` has nothing to map for a password provider (there are no JWT claims), so the normal CLI flow ignores it with a warning; JSON input rejects it. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/docs/route-protect.md` around lines 206 - 208, Clarify the `route
protect` docs so `--claim-header` is not described as always ignored for
password providers: the normal CLI path warns and drops it, but the JSON input
path rejects it. Update the wording in the route-protect documentation to
reflect both behaviors, using the `route protect` command and `--claim-header`
as the key references so users understand the CLI-versus-JSON distinction.
2 participants
What
The route-protect docs page only covered OIDC single sign-on. Password protection has existed in the CLI (
miren auth provider add password,miren route protect --provider <pw>) but was undocumented outside the auto-generated command reference.This adds a Password Protection section to
docs/docs/route-protect.mdcovering:--password,@file)miren route protect(auto-detects provider type)miren_pw_sessioncookie, 24h session, route-bound cookie, logout endpoint--update--forceremoval of attached providersIt also reframes the page intro around both auth modes and does a voice pass over the whole page.
Verified with
bun run build(lint + Docusaurus build pass).Linear
MIR-1261