pstudio is the Studio developer command-line tool. Its login command signs a developer in through Clerk and returns a Clerk-issued token (a JWT). The connector currently reads Clerk tokens only from the __session cookie. The command-line tool has no cookie, so it sends the token in an Authorization: Bearer header instead, and the connector rejects the request with a 401 because it finds no cookie. This issue asks the connector to also read the token from the Bearer header, so that a developer who has signed in through the tool can call the FairData API.
The change
The change lives entirely in clerk_authenticatable. It reads the token from either the __session cookie or an Authorization: Bearer header, verifies it exactly as before against Clerk's public keys, and then reuses the existing logic that maps the token's sub claim to a User record, including the automatic creation of a user on first sign-in. The cookie path, the is_clerk? header dispatch, and the legacy username-and-password path are all left untouched.
The change is already drafted as a small addition, sixteen lines added and one removed, on the branch feat/clerk-bearer-token (commit performant-software/core-data-connector@9c94cdf). I am holding it back from a pull request until it has been verified on staging.
This is not the same request as #584. That issue is about machine authentication for continuous integration and FairCopy Cloud, using API keys. This one is about an individual developer signing in interactively through the command-line tool.
One question for review
The Bearer path does not check the token's iss (issuer) claim. The is_clerk? dispatch and the signature check already separate Clerk tokens from the legacy tokens, so an explicit issuer check looks redundant to me. I would like a second opinion on that before the change lands.
Verification on staging, before the pull request
I will confirm three things on staging. First, that the existing __session cookie sign-in still works. Second, that the legacy username-and-password path, which is used with the User-Agent: node header, still works. Third, that a request carrying a Clerk Bearer token succeeds, including the automatic creation of a first-time user.
pstudiois the Studio developer command-line tool. Itslogincommand signs a developer in through Clerk and returns a Clerk-issued token (a JWT). The connector currently reads Clerk tokens only from the__sessioncookie. The command-line tool has no cookie, so it sends the token in anAuthorization: Bearerheader instead, and the connector rejects the request with a 401 because it finds no cookie. This issue asks the connector to also read the token from the Bearer header, so that a developer who has signed in through the tool can call the FairData API.The change
The change lives entirely in
clerk_authenticatable. It reads the token from either the__sessioncookie or anAuthorization: Bearerheader, verifies it exactly as before against Clerk's public keys, and then reuses the existing logic that maps the token'ssubclaim to aUserrecord, including the automatic creation of a user on first sign-in. The cookie path, theis_clerk?header dispatch, and the legacy username-and-password path are all left untouched.The change is already drafted as a small addition, sixteen lines added and one removed, on the branch
feat/clerk-bearer-token(commit performant-software/core-data-connector@9c94cdf). I am holding it back from a pull request until it has been verified on staging.This is not the same request as #584. That issue is about machine authentication for continuous integration and FairCopy Cloud, using API keys. This one is about an individual developer signing in interactively through the command-line tool.
One question for review
The Bearer path does not check the token's
iss(issuer) claim. Theis_clerk?dispatch and the signature check already separate Clerk tokens from the legacy tokens, so an explicit issuer check looks redundant to me. I would like a second opinion on that before the change lands.Verification on staging, before the pull request
I will confirm three things on staging. First, that the existing
__sessioncookie sign-in still works. Second, that the legacy username-and-password path, which is used with theUser-Agent: nodeheader, still works. Third, that a request carrying a Clerk Bearer token succeeds, including the automatic creation of a first-time user.