ui: Remove KV pre-flight auth check #11968
Conversation
...just let the actual API tell us in the response, thin-client style.
|
👍 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. |
johncowen
force-pushed
the
ui/bugfix/kv-listing-auth
branch
from
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.