-
Notifications
You must be signed in to change notification settings - Fork 394
[PROPOSAL] changes in authorisation required for wallets #13469
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
review-deriv
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.
PR description is too short. You can use this format:
# Description
This is a summary of the changes. This should describe why do we need this change.
Whys and Hows come here.
# Cards
* https://clickup.com/12345
* https://clickup.com/12346
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
A production App ID was automatically generated for this PR. (log)
Click here to copy & paste above information. |
|
🚨 Lighthouse report for the changes in this PR:
Lighthouse ran with https://deriv-app-git-fork-wojciech-deriv-feature-perf-3.binary.sx/ |
|



Problem:
Current way we handle authorize call is prone to race hazards.
Solution for problem:
Subsequent problem:
Above solution require AuthProvider to be added. Which is trivial for wallets and -v2 packages.
Unfortunatelly, against its purpose, /api is actually used in legacy code and even /hooks package. Which is not trivial to separate now.
Also, I have not found acceptable backwards-compatybile method.
Meaning, changes to improve race hazards in wallets would break legacy code :(
Subsequent solution:
Ideally, we should have semver versioning. Given we do not have it at the moment, as an baby step into that direction, introduce /api-v2 package. Block /api from updates to avoid divergent copies of api. Everyone can migrate on its own time (for -v2 migration is trivial, just add , for legacy code is not trivial but also should never be used there to begin with and even current /api might just not work with legacy code whatsover)