Most HTTP API calls will use the default namespace of the calling token to additionally filter/select the data used for the response if one is not specified by the frontend.
The internal permissions/authorize endpoint does not do this (you can ask for permissions from different namespaces in on request).
Therefore this PR adds the tokens default namespace in the frontend only to our calls to the authorize endpoint. I tried to do it in a place that made it feel like it's getting added in the backend, i.e. in a place which was least likely to ever require changing or thinking about.
Note: We are probably going to change this internal endpoint to also inspect the tokens default namespace on the backend. At which point we can revert this commit/PR.
* Add the same support for the tokens default partition
* ui: Ensure dc selector correctly shows the currently selected dc
* ui: Restrict access to non-default partitions in non-primaries (#11420)
This PR restricts access via the UI to only the default partition when in a non-primary datacenter i.e. you can only have multiple (non-default) partitions in the primary datacenter.
* Add Partition to all our models
* Add partitions into our serializers/fingerprinting
* Make some amends to a few adapters ready for partitions
* Amend blueprints to avoid linting error
* Update all our repositories to include partitions, also
Remove enabled/disable nspace repo and just use a nspace with
conditionals
* Ensure nspace and parition parameters always return '' no matter what
* Ensure data-sink finds the model properly
This will later be replaced by a @dataSink decorator but we are find
kicking that can down the road a little more
* Add all the new partition data layer
* Add a way to set the title of the page from inside the route
and make it accessibile via a route announcer
* Make the Consul Route the default/basic one
* Tweak nspace and partition abilities not to check the length
* Thread partition through all the components that need it
* Some ACL tweaks
* Move the entire app to use partitions
* Delete all the tests we no longer need
* Update some Unit tests to use partition
* Fix up KV title tests
* Fix up a few more acceptance tests
* Fixup and temporarily ignore some acceptance tests
* Stop using ember-cli-page-objects fillable as it doesn't seem to work
* Fix lint error
* Remove old ACL related test
* Add a tick after filling out forms
* Fix token warning modal
* Found some more places where we need a partition var
* Fixup some more acceptance tests
* Tokens still needs a repo service for CRUD
* Remove acceptance tests we no longer need
* Fixup and "FIXME ignore" a few tests
* Remove an s
* Disable blocking queries for KV to revert to previous release for now
* Fixup adapter tests to follow async/function resolving interface
* Fixup all the serializer integration tests
* Fixup service/repo integration tests
* Fixup deleting acceptance test
* Fixup some ent tests
* Make sure nspaces passes the dc through for when thats important
* ...aaaand acceptance nspaces with the extra dc param
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
This commit fixes 2 problems with our OIDC flow in the UI, the first is straightforwards, the second is relatively more in depth:
1: A typo (1.10.1 only)
During #10503 we injected our settings service into the our oidc-provider service, there are some comments in the PR as to the whys and wherefores for this change (https://github.com/hashicorp/consul/pull/10503/files#diff-aa2ffda6d0a966ba631c079fa3a5f60a2a1bdc7eed5b3a98ee7b5b682f1cb4c3R28)
Fixing the typo so it was no longer looking for an unknown service (repository/settings > settings)
fixed this.
2: URL encoding (1.9.x, 1.10.x)
TL;DR: /oidc/authorize/provider/with/slashes/code/with/slashes/status/with/slashes should be /oidc/authorize/provider%2Fwith%2Fslashes/code%2Fwith%2Fslashes/status%2Fwith%2Fslashes
When we receive our authorization response back from the OIDC 3rd party, we POST the code and status data from that response back to consul via acallback as part of the OIDC flow. From what I remember back when this feature was originally added, the method is a POST request to avoid folks putting secret-like things into API requests/URLs/query params that are more likely to be visible to the human eye, and POSTing is expected behaviour.
Additionally, in the UI we identify all external resources using unique resource identifiers. Our OIDC flow uses these resources and their identifiers to perform the OIDC flow using a declarative state machine. If any information in these identifiers uses non-URL-safe characters then these characters require URL encoding and we added a helper a while back to specifically help us to do this once we started using this for things that required URL encoding.
The final fix here make sure that we URL encode code and status before using them with one of our unique resource identifiers, just like we do with the majority of other places where we use these identifiers.
The default namespace, and the tokens default namespace (or its origin namespace) is slightly more complicated than other things we deal with in the UI, there's plenty of info/docs on this that I've added in this PR.
Previously:
When a namespace was not specified in the URL, we used to default to the default namespace. When you logged in using a token we automatically forward you the namespace URL that your token originates from, so you are then using the namespace for your token by default. You can of course then edit the URL to remove the namespace portion, or perhaps revisit the UI at the root path with you token already set. In these latter cases we would show you information from the default namespace. So if you had no namespace segment/portion in the URL, we would assume default, perform actions against the default namespace and highlight the default namespace in the namespace selector menu. If you wanted to perform actions in your tokens origin namespace you would have to manually select it from the namespace selector menu.
This PR:
Now, when you have no namespace segment/portion in the URL, we use the token's origin namespace instead (and if you don't have a token, we then use the default namespace like it was previously)
Notes/thoughts:
I originally thought we were showing an incorrectly selected namespace in the namespace selector, but it also matched up with what we were doing with the API, so it was in fact correct. The issue was more that we weren't selecting the origin namespace of the token for the user when a namespace segment was omitted from the URL. Seeing as we automatically forward you to the tokens origin namespace when you log in, and we were correctly showing the namespace we were acting on when you had no namespace segment in the URL (in the previous case default), I'm not entirely sure how much of an issue this actually was.
This characteristic of namespace+token+namespace is a little weird and its easy to miss a subtlety or two so I tried to add some documentation in here for future me/someone else (including some in depth code comment around one of the API endpoints where this is very subtle and very hard to miss). I'm not the greatest at words, so would be great to get some edits there if it doesn't seem clear to folks.
The fact that we used to save your previous datacenter and namespace into local storage for reasons also meant the interaction here was slightly more complicated than it needed to be, so whilst we were here we rejigged things slightly to satisfy said reasons still but not use local storage (we try and grab the info from higher up). A lot of the related code here is from before we had our Routlets which I think could probably make all of this a lot less complicated, but I didn't want to do a wholesale replacement in this PR, we can save that for a separate PR on its own at some point.
* Create BindingRule adapter and tests
* Create BindingRule serializer and test
* Create BindingRule model and repository
* Add binding-rules mock data
* Create binding-rules router and call endpoint
* Create Binding rules tab
* Create and use BindingView component
* Create empty state for BindingView
* Remove binding rule requestForQueryRecord endpoint and tests
* Update binding rules selector to be monospaced
* Add bind type tooltip
* Create and Tabular-dl styling component
* Update hr tag global styling
* Rename BindingView to BindingList and refactor
* Add translations for bind types tooltip info
* Remove unused endpoint
* Refactor based on review notes
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
* Create mock-api endpoints for auth-methods
* Implement auth-method endpoints and model with tests
* Create route and tab for auth-methods
* Create auth-method list and type components with styles
* Add JWT and OIDC svg logos to codebase
* Add brand translations
* Add SearchBar to Auth Methods
* Add acceptance test for Auth Methods UI
* Skip auth method repo test
* Changes from review notes
* Fixup auth-method modela and mock-data
* Update SearhBar with rebased changes
* Add filterBy source and sortBy max token ttl
* Update to SortBy MethodName
* Update UI acceptance tests
* Update mock data DisplayNames
* Skip repo test
* Fix to breaking serializer test
* Implement auth-method endpoints and model with tests
* Add acceptance test for Auth Methods UI
* Update SearhBar with rebased changes
* Add filterBy source and sortBy max token ttl
* Update to SortBy MethodName
* Update UI acceptance tests
* Update mock data DisplayNames
* Fix to breaking serializer test
* Update class for search
* Add auth-methods link to sidebar
* Fixup PR review notes
* Fixup review notes
* Only show OIDC filter with enterprise
* Update conditionals for MaxTokenTTL & TokenLocality
* Refactor
There are many places in the API where we receive a property set to
`null` which can then lead to defensive code deeper in the app in order
to guard for this type of thing when usually we are expecting an array
or for the property to be undefined using omitempty on the backend.
Previously we had two places where we would deal with this in the
serializer using our 'remove-null' util (KV and Intentions).
This new decorator lets you declaritively define this type of data using
a decorator @NullValue([]) (which would replce a null value with [].
@NullValue in turn uses a more generic @replace helper, which we
currently don't need but would let you replace any value with another,
not just a null value.
An additional benefit here is that the guard/replacement is executed
lazily when we get the property instead of serializing all the values
when they come in via the API. On super large datasets, where we only
visualize part of the dataset (say in our scroll panes), this feels like
a good improvement on the previous approach.
Adds a 'status' for the filtering/searching in the UI, without this its not super clear that you are filtering a recordset due to the menu selections being hidden once closed. You can also use the pills in this status view to delete individual filters.
* Add templating to inject JSON into an application/json script tag
Plus an external script in order to pick it out and inject the values we
need injecting into ember's environment meta tag.
The UI still uses env style naming (CONSUL_*) but we uses the new style
JSON/golang props behind the scenes.
Co-authored-by: Paul Banks <banks@banksco.de>
Moves search things around to match an interface that can be switched in and out of fuzzy searching using fuse.js. We add both fuzzy searching and regex based searching to the codebase here, but it is not yet compiled in.
* Use DataLoader errors for Service Detail and Service Instance
* uiCfg > config use the repo-like async interface where possible
* Clean up node show
* Make sure you can put `=` in dev cookie values
* Never default to default
* Tweak chain variable
* Remove env service
* Pass chain through to the template for the tempalte to clean it up
* Delete controller tests
* Remove cleanup in Nodes show as this is still being used in another tab
* Use dc.Local
In order to test certain setups for our metrics visualizations we need to be able to setup several different `ui_config` settings during development/testing. Generally in the UI, we use the Web Inspector to set various cookie values to configure the UI how we need to see it whilst developing, so this PR:
1. Routes `ui_config` through a dev time only `CONSUL_UI_CONFIG` env variable so we can change it via cookies vars.
2. Adds `CONSUL_METRICS_PROXY_ENABLE`, `CONSUL_METRICS_PROVIDER` and `CONSUL_SERVICE_DASHBOARD_URL` so it's easy to set/unset these only values during development.
3. Adds an acceptance testing step so we can setup `ui_config` to whatever we want during testing.
4. Adds an async 'repository-like' method to the `UiConfig` Service so it feels like a repository - incase we ever need to get this via an HTTP API+blocking query.
5. Vaguely unrelated: we allow cookie values to be set via the location.hash whilst in development only e.g. `/ui/services#CONSUL_METRICS_PROXY_ENABLE=1` so we can link to different setups if we ever need to.
All values added here are empty/falsey by default, so in order to see how it was previously you'll need to set the appropriate cookies values, but you can now also easily preview/test the the metrics viz in different/disabled states (with differing `ui_config`)
* ui: Controller dead code removal
This commit removes a little code that became 'dead' as a result of
previous PRs/commits
* Remove a little more from the settings Controller
* Remove CSS related to being able to set the dashboard_url in settings
* Switch upstream-instances to use new style of searchable
* Add search action to DataCollection plus basic README
* Use DataCollection for PowerSelect searching in child-selectors
* Remove old style filterable search for role/policies and instances
* Remove old helpers/components related to search/sort/filter
* ui: Add the most basic workspace root in /ui
* We already have a LICENSE file in the repository root
* Change directory path in build scripts ui-v2 -> ui
* Make yarn install flags configurable from elsewhere
* Minimal workspace root makefile
* Call the new docker specific target
* Update yarn in the docker build image
* Reconfigure the netlify target and move to the higher makefile
* Move ui-v2 -> ui/packages/consul-ui
* Change repo root to refleect new folder structure
* Temporarily don't hoist consul-api-double
* Fixup CI configuration
* Fixup lint errors
* Fixup Netlify target
John Cowen
Kenia