fix(oidc): extract JwtService via app_data instead of web::Data param #91
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/bunyip!91
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/oidc-silent-sso-via-access-token"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Previous commit's
jwt_service: web::Data<Arc<JwtService>>handler param produced a 500 ("Requested application data is not configured correctly") on every /oauth2/authorize because main.rs registers JwtService as a bareArc<JwtService>via.app_data(jwt_service.clone())rather than wrapping it inweb::Data::new(...). Theweb::Data<T>extractor specifically looks forData<T>in the registry; bareArc<T>is invisible to it.Both Drillmark and Mokosh hit the same broken handler (every OIDC client lands at bunyip's /authorize) so both flows 500'd. Fix is to read the bare Arc out of
req.app_datadirectly, matching the pattern bunyip-domain's auth middleware uses (crates/bunyip-domain/src/middleware/auth.rs:160).AuthService stays as a
web::Data<Arc<AuthService>>param because main.rs:594 does wrap that one inweb::Data::new(...). The asymmetric registration is preexisting and not worth re-plumbing in this PR; matching the consumer to whichever shape each service is already registered as keeps the diff bounded.#DMARC-21
Previous commit's `jwt_service: web::Data<Arc<JwtService>>` handler param produced a 500 ("Requested application data is not configured correctly") on every /oauth2/authorize because main.rs registers JwtService as a bare `Arc<JwtService>` via `.app_data(jwt_service.clone())` rather than wrapping it in `web::Data::new(...)`. The `web::Data<T>` extractor specifically looks for `Data<T>` in the registry; bare `Arc<T>` is invisible to it. Both Drillmark and Mokosh hit the same broken handler (every OIDC client lands at bunyip's /authorize) so both flows 500'd. Fix is to read the bare Arc out of `req.app_data` directly, matching the pattern bunyip-domain's auth middleware uses (`crates/bunyip-domain/src/middleware/auth.rs:160`). AuthService stays as a `web::Data<Arc<AuthService>>` param because main.rs:594 does wrap that one in `web::Data::new(...)`. The asymmetric registration is preexisting and not worth re-plumbing in this PR; matching the consumer to whichever shape each service is already registered as keeps the diff bounded. #DMARC-21