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.
The extra argument meant that the blocking query configuration wasn't
being read properly, and therefore the correct ?index wasn't being sent
with the request.
* 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
* Add Routlet service and Route Component
* Add ember-assign-helper (already an indirect dependency)
* Use EventListeners for is-href instead of observing
* Don't include :active in '-intent' styles
We use a `<DataSource @src={{url}} />` component throughout our UI for when we want to load data from within our components. The URL specified as the `@src` is used to map/lookup what is used in to retrieve data, for example we mostly use our repository methods wrapped with our Promise backed `EventSource` implementation, but DataSource URLs can also be mapped to EventTarget backed `EventSource`s and native `EventSource`s or `WebSockets` if we ever need to use those (for example these are options for potential streaming support with the Consul backend).
The URL to function/method mapping previous to this PR used a very naive humongous `switch` statement which was a temporary 'this is fine for the moment' solution, although we'd always wanted to replace with something more manageable.
Here we add `wayfarer` as a dependency - a very small (1kb), very fast, radix trie based router, and use that to perform the URL to function/method mapping.
This essentially turns every `DataSource` into a very small SPA - change its URL and the view of data changes. When the data itself changes, either the yielded view of data changes or the `onchange` event is fired with the changed data, making the externally sourced view of data completely reactive.
```javascript
// use the new decorator a service somewhere to annotate/decorate
// a method with the URL that can be used to access this method
@dataSource('/:ns/:dc/services')
async findAllByDatacenter(params) {
// get the data
}
// can use with JS in a route somewhere
async model() {
return this.data.source(uri => uri`/${nspace}/${dc}/services`)
}
```
```hbs
{{!-- or just straight in a template using the component --}}
<DataSource @src="/default/dc1/services" @onchange="" />
```
This also uses a new `container` Service to automatically execute/import certain services yet not execute them. This new service also provides a lookup that supports both standard ember DI lookup plus Class based lookup or these specific services. Lastly we also provide another debug function called DataSourceRoutes() which can be called from console which gives you a list of URLs and their mappings.
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
* Use NodeName not Node for cross checking proxies/instances
* Also copy over the meta data to keep the correct cursor/index
* When we sync checks to the ProxyInstance replace rather than accumulate
* CSS for moving from a horizontal main menu to a side/vertical one
* Add <App /> Component and rearrange <HashcorpConsul /> to use it
1. HashicorpConsul now uses <App />
2. <App /> is now translated and adds 'skip to main content' functionality
3. Adds ember-in-viewport addon in order to visibly hide main navigation
items in order to take them out of focus/tabbing
4. Slight amends to the dom service while I was there
* ui: Keep track of existing intentions and use those to save changes
Previously we risked overwriting existing data in an intention if we
tried to save an intention without having loaded it first, for example
Description and Metadata would have been overwritten.
This change loads in all the intentions for an origin service so we can
pick off the one we need to save and change to ensure that we don't
overwrite any existing data.
* Rename a model attr to not be overwritten by ember-data
* Make sure we can click on the instances
* Make sure we can click back to the preevious page, not root
* Add a forwards/back/forwards navigation test for service instances
* Rename a model attr to not be overwritten by ember-data
Co-authored-by: John Cowen <jcowen@hashicorp.com>
This PR adds the ns=* query parameter when namespaces are enabled to keep backwards compatibility with how the UI used to work (Intentions page always lists all intention across all namespace you have access to)
I found a tiny dev bug for printing out the current URL during acceptance testing and fixed that up while I was there.
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`)
* Add `Local` property to Datacenters
* If you have not previous datacenter, redirect the user to the local dc
* Add an `is-local` class to the local datacenter in the DC picker
* 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
* Adds model layer changes around HealthChecks
1. Makes a HealthCheck model fragment and uses it in ServiceInstances and
Nodes
2. Manually adds a relationship between a ServiceInstance and its
potential ServiceInstanceProxy
3. Misc changes related to the above such as an Exposed property on
MeshChecks, MeshChecks itself
* Add a potential temporary endpoint to distinguish ProxyServiceInstance
* Fix up Node search bar class
* Add search/sort/filter logic
* Fixup Service default sort key
* Add Healthcheck search/sort/filtering
* Tweak CSS add a default Type of 'Serf' when type is blank
* Fix up tests and new test support
* Add ability to search on Service/Node name depending on where you are
* Fixup CheckID search predicate
* Use computed for DataCollection to use caching
* Alpha sort the Type menu
* Temporary fix for new non-changing style Ember Proxys
* Only special case EventSource proxies
* ui: Ensure search is enabled for child items in the ACLs area
* Refactor comparators to reuse some utility functions
* Add search and sorting to the ACLs child selector
* Add tests for searching within child selectors
* Allow sorting by CreateIndex
This PR updates the tags that we generate for Envoy stats.
Several of these come with breaking changes, since we can't keep two stats prefixes for a filter.
* ui: Add predicate, comparator and necessary files for the search/sort
* Implement search and sort for upstream instance list
* ui: Tweak CSS so its all part of the component
* Remove the old proxy test attribute
* ui: Upgrade ember-data models to use native classes/decorators
* ui: Update remaining ember-data imports
* ui: Move ember-data Adapters to use native classes
* ui: Upgrade serializers to native classes/decorators
* ui: remove meta from roles, they never had it to start with
* ui: Apply native class codemod to all services
* ui: Apply native class codemod to routes
* ui: Apply native class codemod to controllers
* Fix up ember proxy `content` issue
* Add a CreateTime on policy creation
* Minor formatting
* Convert child based saving to use ec instead of custom approach
* Remove custom event source repo wrapping initializer
* Repos here are no longer proxy objects revert to using them normally
* Remove areas of code that were used to set up source backed repos
* Remove local httpGet and shim one in from options
* Add custom httpGet to pass through to provider
* Make a fetch wrapper that adds your token
* Pass the fetch like fetchWithToken wrapper through to the provider
* Fix up httpGet to encode query params again and use fetch-like
* Plumb Datacenter and Namespace to metrics provider in preparation for them being usable.
* Move metrics loader/status to a new component and show reason for being disabled.
* Remove stray console.log
* Rebuild AssetFS to resolve conflicts
* Yarn upgrade
* mend
* 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