ui: Restrict the viewing/editing of certain UI elements based on the users ACLs #9687
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
johncowen
force-pushed
the
ui/feature/permissions
branch
from
390f2eb to
3c06c79
Compare
|
🤔 Double check that this PR does not require a changelog entry in the .changelog directory. Reference |
|
🤔 Double check that this PR does not require a changelog entry in the .changelog directory. Reference |
kaxcode
approved these changes
Feb 11, 2021
added 8 commits
February 19, 2021 15:47
…9706) * Adds a {{disabled}} modifier that works similar to fieldset In that you can set it to false on a parent node and all its sub nodes will be disabled. It has an added improvement that you can then separate allow children if you want to disable everything apart from one thing. One caveat here is that it relies on dom twiddling and is therefore disabling a parent is not currently very reactive and will need some MutationObserver work to make it fully reactive. * Reorganize the base ability for reuse and add canWrite * Add a session ability * Make the mock-api authorize endpoint less brittle and more configurable * Tweak intention write ability to include IsEditable * Add authzing beforeModel hook to let us to configure auth 403s centrally * Centrally configure abilities for allowing certain endpoints * Add session inspection and allow easy access of can from permissions * Implement read/write access based views across KV/Sessions + Intentions * Show notification depending on item.Session * Lint * Only look at path when auto creating nspaced routes * Conditionally show view or edit words based on permissions * Add new step so we can control permissions from acceptance tests * Add tests to assert permissions inspection functionality * Lint * Add CONSUL_RESOURCE_*_* to README
* WIP * Move authorize to the permissions adapter * Slight cleanup and add Resources everywhere * Show a login on the 403 error page * Change to use authorizeBySlug * Add some words around namespaces and permissions * Add correct namespace support * Reorganize authorizeBy things so we can use a slug or set of perms * Clean up new repo methods, tweak DataLoader to deal with 403's nicer * Service > Node * Add some acceptance tests around single item access * Add configuration 'segmented' so we can mark things that shouldn't request * Default permissions to [] * Fix up adapter test
johncowen
force-pushed
the
ui/feature/permissions
branch
from
2d8ca86 to
8623aa8
Compare
johncowen
changed the title
|
🍒 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/329527. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR builds on the minimal permission inspection we were using in order to decide whether to show the 'Manage Namespace' menu item for operators.
As we are likely to be doing this kind of thing a lot more often, we've used
ember-canand followed the approach used by other products using this addon/functionality.The user facing impact of this is that we now only show certain main menu items depending on whether you have read access to them or not. For example, if your ACL token doesn't have read access to KV, then we don't show you the KV navigation link in the main navigation.
We've added a very simple acceptance test only here as there are more upcoming tasks related to this which will probably mean us backing some of the work here with
ember-datain order to follow the patterns used by the rest of the app, and I felt it would be a good idea to implement another feature related to this first before deciding on whether/how we should do this. Once this is done we'll probably add a little more testing around this also.