feat: add x-tinyauth-location to nginx response#783
Conversation
Solves #773. Normally you let Nginx handle the login URL creation but with this "hack" we can set an arbitary header with where Tinyauth wants the user to go to. Later the Nginx error page can get this header and redirect accordingly.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughCentralized proxy error-redirect URL construction and unified 401/403 handling: the controller now sets an Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #783 +/- ##
==========================================
+ Coverage 19.97% 20.12% +0.15%
==========================================
Files 50 50
Lines 3960 3970 +10
==========================================
+ Hits 791 799 +8
+ Misses 3100 3099 -1
- Partials 69 72 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Documentation Updates 2 document(s) were updated by changes in this PR: headersView Changes@@ -36,6 +36,10 @@
### Remote sub
The `Remote-Sub` header contains the subject identifier of the currently logged-in user, retrieved from the `sub` claim in the OIDC server. This can be used to uniquely identify the user across different authentication providers.
+
+### X-Tinyauth-Location
+
+The `x-tinyauth-location` header contains the redirect URL when authentication or authorization fails. This header is included in 401, 403, and 500 responses for non-browser clients (like Nginx auth_request module) and indicates where the client should redirect the user (e.g., `/login` or `/unauthorized` with appropriate query parameters). This allows proxy servers to use custom error pages that read this header and perform redirects dynamically, rather than hardcoding redirect URLs in the proxy configuration.
### Custom headers
nginx-proxy-managerView Changes@@ -118,19 +118,21 @@
technologies like WebSockets.
:::
-:::note
- Due to the way Nginx handles forward auth, Tinyauth cannot automatically redirect to the unauthorized page. Thus, users may be redirected to a blank 403 Forbidden page in case of a failed authentication. This can be somehow mitigated by configuring a custom error page for the 403 status code:
+:::tip
+ Tinyauth sets the `x-tinyauth-location` header with the redirect URL for non-browser and forward-auth clients. This can be used to dynamically redirect users instead of using hardcoded URLs:
```sh
location / {
# Rest of your configuration
- error_page 403 = @tinyauth_unauthorized;
+ error_page 401 403 = @tinyauth_error;
}
- location @tinyauth_unauthorized {
- return 302 http://tinyauth.example.com/unauthorized?username=unavailable; # Replace with your app URL
+ location @tinyauth_error {
+ return 302 $upstream_http_x_tinyauth_location;
}
```
+
+ This handles both login redirects (401) and unauthorized page redirects (403) automatically.
:::
Save the host configuration. Accessing the protected host will redirect to the Tinyauth login page if not already logged in. Repeat this process for each host to be protected by Tinyauth. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/controller/proxy_controller_test.go`:
- Line 119: The assertions using testify's assert.Equal in
internal/controller/proxy_controller_test.go are passing (actual, expected)
instead of (expected, actual); update all assert.Equal calls (e.g., the call
comparing variable location to the URL string — the assert.Equal invocation
referencing location and "https://tinyauth.example.com/login?redirect_uri=..."
and the other instances at the same file) to swap the arguments so the expected
literal/string is the second-to-last parameter and the actual variable (e.g.,
location) is the last parameter; apply this same swap to the other occurrences
noted (lines near 131, 146, 162, 177, 193) for every assert.Equal usage in that
test.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3f981954-a11c-4913-ab0b-d8acdd3c4117
📒 Files selected for processing (2)
internal/controller/proxy_controller.gointernal/controller/proxy_controller_test.go
Solves #773. Normally you let Nginx handle the login URL creation but with this "hack" we can set an arbitary header with where Tinyauth wants the user to go to. Later the Nginx error page can get this header and redirect accordingly.
Summary by CodeRabbit
Bug Fixes
Tests