-
Notifications
You must be signed in to change notification settings - Fork 1
Add dynamic auth token updates #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Adds update_auth/2 and :auth option for invoke/3 to support token rotation like JS client's setAuth(). Closes supabase-community#3
| case opts[:auth] do | ||
| nil -> client | ||
| auth_token when is_binary(auth_token) -> update_auth(client, auth_token) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for only 2 logic branches, i would go with a simpler if/2, so we can follow the rest of project standard
| timeout = opts[:timeout] || 15_000 | ||
|
|
||
| client | ||
| # Handle auth token override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| # Handle auth token override |
| ### Benefits | ||
|
|
||
| - **Token rotation support**: Easily update tokens without recreating clients | ||
| - **Better performance**: Avoid the overhead of creating new client instances | ||
| - **Flexibility**: Use different tokens per request or update client globally | ||
| - **Feature parity**: Matches the JavaScript client's `setAuth()` functionality | ||
| - **Immutability**: Original client instances remain unchanged with functional updates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think this kind of content fits well on a README
| ### Benefits | |
| - **Token rotation support**: Easily update tokens without recreating clients | |
| - **Better performance**: Avoid the overhead of creating new client instances | |
| - **Flexibility**: Use different tokens per request or update client globally | |
| - **Feature parity**: Matches the JavaScript client's `setAuth()` functionality | |
| - **Immutability**: Original client instances remain unchanged with functional updates |
| - **Comprehensive timeout coverage**: Sets both receive timeout (per-chunk) and request timeout (complete response) | ||
| - **Feature parity with JS client**: Matches timeout functionality in the JavaScript SDK | ||
|
|
||
| ## Dynamic Auth Token Updates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this section at all seems not to fit on a README file
| - **Request cancellation**: Long-running requests will timeout and be cancelled | ||
| - **Better resource management**: Prevents hanging connections | ||
| - **Comprehensive timeout coverage**: Sets both receive timeout (per-chunk) and request timeout (complete response) | ||
| - **Feature parity with JS client**: Matches timeout functionality in the JavaScript SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
existing section i know, but isn't necessary to explicit say we have feature parity with JS, this is implicit
| | {:region, region} | ||
| | {:on_response, on_response} | ||
| | {:timeout, pos_integer()} | ||
| | {:auth, String.t()} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JS uses auth as the override token option key? maybe we could think on something like access_token or authorization_token, wdyt?
Adds update_auth/2 and :auth option for invoke/3 to support token rotation like JS client's setAuth(). Closes #3