cliffracer-auth
JWT authentication for cliffracer services, on the per-message hook chain.
Declare it like any other extension. Verification runs in worker_setup, before
the handler. A handler that reaches its body has been authenticated.
from cliffracer import CliffracerService, ServiceConfig, rpc
from cliffracer_auth import AuthConfig, AuthExtension, SimpleAuthService, get_current_user
class Orders(CliffracerService):
auth = AuthExtension(SimpleAuthService(AuthConfig(secret_key=SECRET)))
@rpc
async def create(self, item: str) -> dict[str, str]:
return {"item": item, "by": get_current_user().username}
secret_key must be at least 32 characters.
The bearer token is read from the authorization header. The header name is
compared in lower case, so a publisher may set Authorization or
authorization.
Three things are refused: a message with no token, a message with an invalid
one, and a message whose backend raised while checking. All three get
refused: unauthenticated.
Authorization
requires_auth, requires_roles and requires_permissions read the identity
the extension established:
@rpc
@requires_roles("admin")
async def delete_everything(self) -> None: ...
A caller holding a token but lacking the role gets Required roles: ('admin',).
The identity lives in a contextvar. The extension sets it in worker_setup and
resets it in worker_teardown, and carries the reset token in that dispatch's
own ctx.data. Keeping the token per dispatch is what makes concurrent
dispatches safe: a token set in one dispatch's context and reset in another's
raises inside worker_teardown.
Refusing a message
The extension refuses by raising RejectMessage. That is core's rejection
channel, and the one hook exception that stops the handler running. Core
swallows every other hook exception so that a faulty extension leaves dispatch
working, which is why a refusal needs its own channel.
The container turns a refusal into the RPC error response, runs worker_result
with it, and acks the message. A refusal is policy working.
Using a different issuer
AuthExtension accepts any object with a validate_token(token) method.
SimpleAuthService is one. Swap it to verify against another issuer and the
hook chain, the refusal path and the decorators stay as they are. The parameter
is annotated SimpleAuthService; the annotation is the narrow part, and duck
typing works.
Return an AuthContext carrying a user and a future expires_at, or return
None.
The extension gates on context.is_authenticated, which is
user is not None and is_valid, and is_valid requires expires_at to be set
and in the future. An issuer must set expires_at in the future for authentication
to succeed; otherwise requests are refused as unauthenticated.
Raising from validate_token is safe. The extension turns the exception into a
refusal and logs it under the extension's name.
Installed from PyPI, versioned in lockstep with cliffracer.
Metadata
Release files for cliffracer-auth 1.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| cliffracer_auth-1.0.0.tar.gz | 18.4 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| cliffracer_auth-1.0.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 29.1 kB
Release files / cliffracer_auth-1.0.0.tar.gz
| Download URL | cliffracer_auth-1.0.0.tar.gz |
|---|---|
| Size | 18.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
de544bee4be491690ceef5bfc80f18d925a6f5a28cb68bc54e881cf189581fcc
|
|
BLAKE2b-256 checksum How to use checksums |
f6553520bdba75b9ec2f3434cb3bbb18297cff753327f222469207fdd9cb4b70
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.12.13 {"installer":{"name":"uv","version":"0.12.13","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / cliffracer_auth-1.0.0-py3-none-any.whl
| Download URL | cliffracer_auth-1.0.0-py3-none-any.whl |
|---|---|
| Size | 10.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
2508bb73d5da5f62736828b6be854560f0bca6710391ebbcf4a003c8804174f5
|
|
BLAKE2b-256 checksum How to use checksums |
870c88d9b323a19530ffe6a0cf1f91e888053d3ba9c194fc28309b24248edb3a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.12.13 {"installer":{"name":"uv","version":"0.12.13","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for cliffracer-auth 1.0.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.