github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'eacb73cb78'
${ noResults }
consul/ui/packages/consul-ui/tests/acceptance/navigation-links.feature

34 lines
827 B
Raw Normal View History Unescape

ui: Restrict the viewing/editing of certain UI elements based on the users ACLs (#9687) This commit use the internal authorize endpoint along wiht ember-can to further restrict user access to certain UI features and navigational elements depending on the users ACL token
4 years ago
@setupApplicationTest
Feature: navigation-links: Main Navigation link visibility
Scenario: No read access to Key/Values
Given 1 datacenter model with the value "dc-1"
And the url "/v1/internal/acl/authorize" responds with from yaml
---
body:
- Resource: operator
Access: write
Allow: true
- Resource: service
Access: read
Allow: true
- Resource: node
Access: read
Allow: true
- Resource: key
Access: read
ui: Always show main navigation Key/Value link (#10916) * ui: Ignore response from API for KV permissions Currently there is no way for us to use our HTTP authorization API endpoint to tell us whether a user has access to any KVs (including the case where a user may not have access to the root KV store, but do have access to a sub item) This is a little weird still as in the above case the user would click on this link and still get a 403 for the root, and then have to manually type in the URL for the KV they do have access to. Despite this we think this change makes sense as at least something about KV is visible in the main navigation. Once we have the ability to know if any KVs are accessible, we can add this guard back in. We'd initially just removed the logic around the button, but then noticed there may be further related KV issues due to the nested nature of KVs so we finally decided on simply ignoring the responses from the HTTP API, essentially reverting the KV area back to being a thin client. This means when things are revisited in the backend we can undo this easily change in one place. * Move acceptance tests to use ACLs perms instead of KV ones
3 years ago
Allow: true
ui: Restrict the viewing/editing of certain UI elements based on the users ACLs (#9687) This commit use the internal authorize endpoint along wiht ember-can to further restrict user access to certain UI features and navigational elements depending on the users ACL token
4 years ago
- Resource: intention
Access: read
Allow: true
- Resource: acl
Access: read
ui: Always show main navigation Key/Value link (#10916) * ui: Ignore response from API for KV permissions Currently there is no way for us to use our HTTP authorization API endpoint to tell us whether a user has access to any KVs (including the case where a user may not have access to the root KV store, but do have access to a sub item) This is a little weird still as in the above case the user would click on this link and still get a 403 for the root, and then have to manually type in the URL for the KV they do have access to. Despite this we think this change makes sense as at least something about KV is visible in the main navigation. Once we have the ability to know if any KVs are accessible, we can add this guard back in. We'd initially just removed the logic around the button, but then noticed there may be further related KV issues due to the nested nature of KVs so we finally decided on simply ignoring the responses from the HTTP API, essentially reverting the KV area back to being a thin client. This means when things are revisited in the backend we can undo this easily change in one place. * Move acceptance tests to use ACLs perms instead of KV ones
3 years ago
Allow: false
ui: Restrict the viewing/editing of certain UI elements based on the users ACLs (#9687) This commit use the internal authorize endpoint along wiht ember-can to further restrict user access to certain UI features and navigational elements depending on the users ACL token
4 years ago
---
When I visit the services page for yaml
---
dc: dc-1
---
Then I see services on the navigation
ui: Always show main navigation Key/Value link (#10916) * ui: Ignore response from API for KV permissions Currently there is no way for us to use our HTTP authorization API endpoint to tell us whether a user has access to any KVs (including the case where a user may not have access to the root KV store, but do have access to a sub item) This is a little weird still as in the above case the user would click on this link and still get a 403 for the root, and then have to manually type in the URL for the KV they do have access to. Despite this we think this change makes sense as at least something about KV is visible in the main navigation. Once we have the ability to know if any KVs are accessible, we can add this guard back in. We'd initially just removed the logic around the button, but then noticed there may be further related KV issues due to the nested nature of KVs so we finally decided on simply ignoring the responses from the HTTP API, essentially reverting the KV area back to being a thin client. This means when things are revisited in the backend we can undo this easily change in one place. * Move acceptance tests to use ACLs perms instead of KV ones
3 years ago
Then I don't see roles on the navigation
ui: Restrict the viewing/editing of certain UI elements based on the users ACLs (#9687) This commit use the internal authorize endpoint along wiht ember-can to further restrict user access to certain UI features and navigational elements depending on the users ACL token
4 years ago