-
Notifications
You must be signed in to change notification settings - Fork 224
feat(auth): introduce WithinBody option for AuthMode #1297
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
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
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?
@tkrugg
tkrugg
Aug 6, 2021
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:
|
@tkrugg
tkrugg
left a comment
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
jpreynat
commented
Dec 17, 2021
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
jpreynat
commented
Jan 3, 2022
Thanks for the suggestion @Haroenv. But sadly we already tried using withinHeaders and we have some cases where the limit is too small for us, preventing us from switching from version 3 to version 4.
Are there any plans on your side to have the withinBody option released at some point?
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)
humanbagel
commented
May 19, 2022
@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
BohdanYavorskyi
commented
May 9, 2024
@nunomaduro what's the issue that this PR not merged? Enterprise-level apps need that a lot :(
Uh oh!
There was an error while loading. Please reload this page.
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