-
Notifications
You must be signed in to change notification settings - Fork 222
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
feat(auth): introduce WithinBody option for AuthMode #1297
base: v4
Are you sure you want to change the base?
Conversation
fixes #1035 Implementation is done by: - adding a new auth mode - adding data as the return type for createAuth - expose data from transporter - serialize transporter data - map api key back to query parameter if GET
@@ -40,6 +40,8 @@ export function retryableRequest<TResponse>( | |||
request.method !== MethodEnum.Get | |||
? {} | |||
: { | |||
// if AuthMode.WithinData, we forcibly map apiKey back to a query param | |||
'x-algolia-api-key': transporter.data?.apiKey, |
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 might be implemented wrong?
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.
Not sure what you mean by "wrong", but I have a extra question: is the idea here to move auth of all non GET requests to the body?
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 9281ee9:
|
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 agree with the change, but can we have a test securing this behaviour?
it's in the todo @tkrugg |
Sorry, there was too many places to change in this unplanned PR, but withinHeaders should be an in-between solution, as it has a higher limit (but doesn't avoid a cors preflight request) @jpreynat |
Thanks for the suggestion @Haroenv. But sadly we already tried using |
At the moment it's not yet on the roadmap, as I made this pull request a while ago in an experiment. I will however ask the current owners of this repo whether they can take a look (@shortcuts, @millotp) |
@Haroenv @shortcuts @millotp @tkrugg can this prioritized now? it's really preventing enterprise users from the full performance benefits of algolia if we can't use long secured api keys from the browser |
Sorry, I'm not on this team anymore @humanbagel, but I do know that algoliasearch v3 had this feature, so you can use that before it's prioritised to be fixed. Someone who's actually on the api clients team can give more information on prioritisation |
@nunomaduro what's the issue that this PR not merged? Enterprise-level apps need that a lot :( |
fixes #1035
Implementation is done by:
This doesn't automatically switch to body if the key is too long, the option authMode needs to be set
TODO