feat(client): bearer and API-key authentication - #10
Open
gustavorps wants to merge 2 commits into
Open
Conversation
Additive AuthMethod override (AuthApply extension trait): Basic remains the default; with_bearer()/with_api_key() switch the Authorization header. All request paths now funnel through apply_auth; the SSE manager carries the same override for its connection. Grounding: DFRNT hub Personal Access Tokens (TERMINUSDB_ACCESS_TOKEN).
Review vs terminusdb-client-js: formatAuthHeader maps apikey -> 'Token' and the v12 docs (push-to-project.md) show 'Authorization(-Remote): Token <PAT>'. The previous 'Apikey <key>' scheme would be rejected by the server/cloud auth.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Rust client only supports Basic auth. The JavaScript client supports API keys and bearer tokens, and the TerminusDB cloud (DFRNT hub) authenticates with Personal Access Tokens (
TERMINUSDB_ACCESS_TOKEN) — so Rust users cannot talk to managed deployments at all.Design
Additive, no breaking change:
AuthMethodenum:Basic { user, pass } | Bearer(String) | ApiKey(String)AuthApplyextension trait onRequestBuilder— every request path funnels through it;Basic/no override reproduces the historical.basic_auth()behavior exactlywith_bearer(token)/with_api_key(key)(client.rs)sse_manager.rs) carries the same overrideThe header forms are the ones the server accepts:
Bearer <token>Apikey <key>Tests
auth_tests.rs— unit-verified header construction for all three methods (default_client_uses_basic_auth,bearer_override_sets_authorization_header,api_key_override_sets_authorization_header). Green oncargo test -p terminusdb-client --lib.Notes
docs/terminusdb/get-your-api-key.md.basic_auth(...)→.apply_auth(self)); the collaborationAuthorization-Remoteheader is intentionally untouched (separate concern, see PR fix(client): Authorization-Remote header casing #9)