-
-
Notifications
You must be signed in to change notification settings - Fork 154
SSO: custom claim support, fixing login stability issues, and ensuring correct redirection #982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
introduces an async oidc_state.get_client
This enhancement allows SQLPage to read and utilize custom claims from JWT tokens generated by OIDC providers, enabling users to store additional information like roles or permissions that can be used in SQL queries. Key changes: - Modified get_token_claims() to accept optional login state, allowing token verification without requiring active login session state - Updated nonce verification logic to handle cases where no login state exists - Refactored OIDC client and token response types to use more specific generics that support additional claims through OidcAdditionalClaims - Simplified function signatures by passing oidc_state instead of separate client and config parameters - Enhanced error handling in OIDC callback processing with automatic client refresh - Updated type definitions to properly support custom claim extraction from tokens This enables SSO providers to include custom user metadata that SQLPage can access and use for authorization and personalization in database queries.
ownership - Extract request handling logic into standalone async functions - Replace service ownership with Rc<S> for better memory management - Simplify get_client() return type to use MutexGuard directly - Add MiddlewareResponse enum to clarify response handling flow - Move public path checking to beginning of request pipeline - Reorganize code to separate concerns and improve readability
This change switches from std::sync::Mutex to tokio::sync::RwLock for the OIDC client to avoid deadlocks. The read operations now use a shared lock while writes remain exclusive.
Moves client refresh logic into a separate method and uses request-scoped HTTP client instead of storing AppConfig. This simplifies the state struct and improves the refresh mechanism's reliability.
This commit adds automatic OIDC provider metadata refresh when token validation fails. Previously, tokens would become invalid when providers rotated their signing keys, requiring a manual SQLPage restart to refresh the metadata.
- Store initial URL in OidcLoginState. - Use initial URL when building redirect response on callback error.
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.
SQLPage can now read custom claims from Single-Sign-On (SSO) tokens. This allows you to configure your identity provider to include user-specific data, such as roles or permissions, directly in the login token. This information becomes available in your SQL queries, enabling you to build pages that dynamically adapt their content to the authenticated user.
A bug that caused SSO logins to fail over time has been fixed. The issue occurred because identity providers regularly rotate their security keys, but SQLPage previously only fetched them at startup. The application now automatically refreshes this provider metadata periodically and after login errors, ensuring stable authentication without requiring manual restarts.
Post-login redirection after authentication errors has been improved to preserve the user's original destination. If a user navigates to a page with specific URL parameters and is prompted to log in, the application now correctly remembers the full URL. After successful authentication, they are returned to the exact page with all its parameters intact.