robertpofuk commented on code in PR #72262:
URL: https://github.com/apache/airflow/pull/72262#discussion_r4092231332
##########
providers/edge3/src/airflow/providers/edge3/worker_api/auth.py:
##########
@@ -52,7 +53,15 @@ class WorkerTokenAuthorization(TypedDict, total=False):
authorized: bool
-def _default_jwt_verifier(claims: dict) -> WorkerTokenAuthorization:
+@dataclass(frozen=True)
+class WorkerTokenContext:
+ """Request context passed to a ``[edge] jwt_verifier`` alongside the token
claims."""
Review Comment:
Good point on the worker-addressing use case. I kept WorkerTokenContext
minimal for the first cut — expose the least now, extend when there's a
concrete requirement — and I'd rather grow the context with request field than
pass the raw Request as param. Request isn't the only thing we'll want to hand
the verifier (e.g. whether teams are enabled), so it'd end up as an attribute
of the context anyway — and passing it whole leaks Starlette into the
soon-to-be-public verifier contract.
To be clear on scope: this function does not hand off JWT verification and
it never should because we would lower the security barrier.
Signature/issuer/audience validation stays in core (JWTValidator against
trusted_jwks_url, with jwt_issuer/jwt_audience); jwt_verifier only answers the
narrower "may this validated identity act as a worker?" question. method here
is the existing concept for the API path after /edge_worker/v1/ (same one
_check_method_claim uses), documented on the field.
I would still keep claims as first params because i think most of use cases
will be simple token validation and this will keep most of implementations
clean and simple.
Regarding worker name i would for now stick with methd. method is
pre-existing vocabulary in this module and I can gladely in future extend
context with more attributes that would improve usubility. In this PR i would
keep it to minimum API surface towards verifier.
On that note, Happy to go either way — both solve the immediate need.
--
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]
