Yicong-Huang opened a new pull request, #4903: URL: https://github.com/apache/texera/pull/4903
### What changes were proposed in this PR? `org.apache.texera.auth.JwtAuthFilter` (the 4 microservices) silently passes a request through when the Bearer token is missing or invalid; the `401` only surfaces later in Dropwizard's `@Auth` injection. amber's path (toastshaman) instead returns `401` directly from the filter with a `WWW-Authenticate` challenge. Align the microservice filter: - **No `Authorization: Bearer …` header** → throw `401` with `WWW-Authenticate: Bearer realm="texera"` (RFC 6750 §3 bare challenge). - **Header present but token verification / claim extraction fails** → throw `401` with `error="invalid_token"` so a well-behaved client can discard a bad token instead of retrying. - **Header present and valid** → install `SecurityContext` as before. **`@PermitAll` opt-out** (JSR-250). A resource method or class annotated `@PermitAll` skips the eager `401` *only* on the no-header path; `@Auth Optional[SessionUser]` is then injected as empty. An invalid token still `401`s — a tampered / stale token is never silently treated as anonymous. The single in-tree consumer of the optional pattern is `file-service/.../DatasetResource.getDatasetCover` (anonymous read of public dataset covers); annotated with `@PermitAll`. Failure is signaled by **throwing `WebApplicationException`** instead of `abortWith` — JAX-RS-idiomatic, and composes with Dropwizard's `WebApplicationExceptionCatchingFilter` if anyone reaches for it later. ### Any related issues, documentation, discussions? Closes #4901 Out of scope and worth filing separately: `RolesAllowedDynamicFeature` is registered only in amber (`TexeraWebApplication`, `ComputingUnitMaster`). The 4 microservices have `@RolesAllowed` annotations that are currently decorative — not enforced. `workflow-compiling-service` is even stricter: it has `@RolesAllowed` and registers neither `JwtAuthFilter` nor `RolesAllowedDynamicFeature`. Both gaps are independent of this PR. ### How was this PR tested? `JwtAuthFilterSpec` (new, 9 cases): no header / non-Bearer / unverifiable / valid Bearer on a required-auth method; method-level `@PermitAll` (unauthenticated passes / invalid token still 401 / valid token sets context); class-level `@PermitAll`; and a resource-info-absent fallback to required-auth. `sbt Auth/test` 25/25 green; format / lint clean; all 4 microservices recompile cleanly. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.7) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
