-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
ui: Remove KV pre-flight auth check #11968
Conversation
...just let the actual API tell us in the response, thin-client style.
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 if you have a feature flag system in place but could this be a feature flag? That may make it more visible so it's not forgotten. Also a small change so might not be worth it.
👍 ty! Yeah we could have feature flagged this with code I suppose. I kinda have here, I'm planning on just search for the issue number once the backend issue is resolved, which is kind of like a poor mans feature flag, hence the extra comments in the code I've not changed. tbh I'm not even sure when the backend API issue is going to be resolved. I suppose also code based feature flagging would involve injecting our env service, adding the flags, probably deciding on what to call the flag etc etc, basically a bunch of code that we will just remove once the backend it fixed. I guess I'm thinking code based feature flagging would be more for being able to turn things on and off and on and off etc etc multiple times, or maybe to be able to work on a feature only in certain environments, not just for enabling something once its working and thats the end of it. |
7873699
to
d553992
Compare
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/543441. |
🍒✅ Cherry pick of commit d9a315e onto |
* ui: Don't even ask whether we are authorized for a KV... ...just let the actual API tell us in the response, thin-client style. * Add some similar commenting for previous PRs related to this problem
* ui: Don't even ask whether we are authorized for a KV... ...just let the actual API tell us in the response, thin-client style. * Add some similar commenting for previous PRs related to this problem
Related to #11098
This PR removes the KV pre-flight check to the internal authorization endpoint and instead relies on the response from the normal KV endpoint, thin client style.