d1b3a63b2f
In some circumstances a consul 1.4 client could be running in an un-upgraded 1.3 or lower cluster. Currently this gives a 500 error on the new ACL token endpoint. Here we catch this specific 500 error/message and set the users AccessorID to null. Elsewhere in the frontend we use this fact (AccessorID being null) to decide whether to present the legacy or the new ACL UI to the user. Also: - Re-adds in most of the old style ACL acceptance tests, now that we are keeping the old style UI - Restricts code editors to HCL only mode for all `Rules` editing (legacy/'half legacy'/new style) - Adds a [Stop using] button to the old style ACL rows so its possible to logout. - Updates copy and documentation links for the upgrade notices
41 lines
1.2 KiB
Gherkin
41 lines
1.2 KiB
Gherkin
@setupApplicationTest
|
|
Feature: token headers
|
|
In order to authenticate with tokens
|
|
As a user
|
|
I need to be able to specify a ACL token AND/OR leave it blank to authenticate with the API
|
|
Scenario: Arriving at the index page having not set a token previously
|
|
Given 1 datacenter model with the value "datacenter"
|
|
When I visit the index page
|
|
Then the url should be /datacenter/services
|
|
And a GET request is made to "/v1/catalog/datacenters" from yaml
|
|
---
|
|
headers:
|
|
X-Consul-Token: ''
|
|
---
|
|
Scenario: Set the token to [Token] and then navigate to the index page
|
|
Given 1 datacenter model with the value "datacenter"
|
|
And the url "/v1/acl/tokens" responds with a 403 status
|
|
When I visit the tokens page for yaml
|
|
---
|
|
dc: datacenter
|
|
---
|
|
Then the url should be /datacenter/acls/tokens
|
|
Then I fill in with yaml
|
|
---
|
|
secret: [Token]
|
|
---
|
|
And I submit
|
|
When I visit the index page
|
|
Then the url should be /datacenter/services
|
|
And a GET request is made to "/v1/catalog/datacenters" from yaml
|
|
---
|
|
headers:
|
|
X-Consul-Token: [Token]
|
|
---
|
|
Where:
|
|
---------
|
|
| Token |
|
|
| token |
|
|
| '' |
|
|
---------
|