2023-03-14 13:18:55 +00:00
|
|
|
/**
|
|
|
|
* Copyright (c) HashiCorp, Inc.
|
2023-08-11 13:12:13 +00:00
|
|
|
* SPDX-License-Identifier: BUSL-1.1
|
2023-03-14 13:18:55 +00:00
|
|
|
*/
|
|
|
|
|
2020-05-05 16:29:35 +00:00
|
|
|
import { inject as service } from '@ember/service';
|
2020-11-09 09:25:35 +00:00
|
|
|
import RepositoryService from 'consul-ui/services/repository';
|
2020-05-05 16:29:35 +00:00
|
|
|
import { getOwner } from '@ember/application';
|
|
|
|
import { set } from '@ember/object';
|
2021-02-23 08:56:42 +00:00
|
|
|
import dataSource from 'consul-ui/decorators/data-source';
|
2020-05-05 16:29:35 +00:00
|
|
|
|
|
|
|
const modelName = 'oidc-provider';
|
|
|
|
const OAUTH_PROVIDER_NAME = 'oidc-with-url';
|
2020-11-09 09:25:35 +00:00
|
|
|
export default class OidcProviderService extends RepositoryService {
|
ui: Don't default to the default namespace, use the token default namespace instead (#10503)
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.
2021-07-07 10:46:41 +00:00
|
|
|
@service('torii') manager;
|
2021-08-24 15:58:45 +00:00
|
|
|
@service('settings') settings;
|
2020-11-09 09:25:35 +00:00
|
|
|
|
|
|
|
init() {
|
|
|
|
super.init(...arguments);
|
2020-05-05 16:29:35 +00:00
|
|
|
this.provider = getOwner(this).lookup(`torii-provider:${OAUTH_PROVIDER_NAME}`);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
getModelName() {
|
2020-05-05 16:29:35 +00:00
|
|
|
return modelName;
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
2021-09-15 18:50:11 +00:00
|
|
|
@dataSource('/:partition/:ns/:dc/oidc/providers')
|
2021-02-23 08:56:42 +00:00
|
|
|
async findAllByDatacenter() {
|
2021-11-24 14:53:12 +00:00
|
|
|
const res = await super.findAllByDatacenter(...arguments);
|
|
|
|
if (res.length === 0) {
|
|
|
|
const err = new Error('Not found');
|
|
|
|
err.statusCode = 404;
|
|
|
|
this.store.adapterFor(this.getModelName()).error(err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
return res;
|
2021-02-23 08:56:42 +00:00
|
|
|
}
|
|
|
|
|
2021-09-15 18:50:11 +00:00
|
|
|
@dataSource('/:partition/:ns/:dc/oidc/provider/:id')
|
ui: Don't default to the default namespace, use the token default namespace instead (#10503)
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.
2021-07-07 10:46:41 +00:00
|
|
|
async findBySlug(params) {
|
|
|
|
// This addition is mainly due to ember-data book-keeping This is one of
|
|
|
|
// the only places where Consul w/namespaces enabled doesn't return a
|
|
|
|
// response with a Namespace property, but in order to keep ember-data
|
|
|
|
// id's happy we need to fake one. Usually when we make a request to consul
|
|
|
|
// with an empty `ns=` Consul will use the namespace that is assigned to
|
|
|
|
// the token, and when we get the response we can pick that back off the
|
|
|
|
// responses `Namespace` property. As we don't receive a `Namespace`
|
2022-01-11 11:02:46 +00:00
|
|
|
// property here, we have to figure this out ourselves. But we also want
|
ui: Don't default to the default namespace, use the token default namespace instead (#10503)
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.
2021-07-07 10:46:41 +00:00
|
|
|
// to make this completely invisible to 'the application engineer/a
|
|
|
|
// template engineer'. This feels like the best place/way to do it as we
|
|
|
|
// are already in a asynchronous method, and we avoid adding extra 'just
|
|
|
|
// for us' parameters to the query object. There is a chance that as we
|
|
|
|
// are discovering the tokens default namespace on the frontend and
|
|
|
|
// assigning that to the ns query param, the token default namespace 'may'
|
|
|
|
// have changed by the time the request hits the backend. As this is
|
|
|
|
// extremely unlikely and in the scheme of things not a big deal, we
|
|
|
|
// decided that doing this here is ok and avoids doing this in a more
|
|
|
|
// complicated manner.
|
|
|
|
const token = (await this.settings.findBySlug('token')) || {};
|
|
|
|
return super.findBySlug({
|
|
|
|
ns: params.ns || token.Namespace || 'default',
|
2022-01-11 11:02:46 +00:00
|
|
|
partition: params.partition || token.Partition || 'default',
|
ui: Don't default to the default namespace, use the token default namespace instead (#10503)
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.
2021-07-07 10:46:41 +00:00
|
|
|
dc: params.dc,
|
|
|
|
id: params.id,
|
|
|
|
});
|
2021-02-23 08:56:42 +00:00
|
|
|
}
|
|
|
|
|
2021-09-15 18:50:11 +00:00
|
|
|
@dataSource('/:partition/:ns/:dc/oidc/authorize/:id/:code/:state')
|
2021-02-23 08:56:42 +00:00
|
|
|
authorize(params, configuration = {}) {
|
|
|
|
return this.store.authorize(this.getModelName(), params);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
logout(id, code, state, dc, nspace, configuration = {}) {
|
2020-05-05 16:29:35 +00:00
|
|
|
// TODO: Temporarily call this secret, as we alreayd do that with
|
|
|
|
// self in the `store` look to see whether we should just call it id like
|
|
|
|
// the rest
|
|
|
|
const query = {
|
|
|
|
id: id,
|
|
|
|
};
|
|
|
|
return this.store.logout(this.getModelName(), query);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
close() {
|
2020-05-05 16:29:35 +00:00
|
|
|
this.manager.close(OAUTH_PROVIDER_NAME);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
findCodeByURL(src) {
|
2020-05-05 16:29:35 +00:00
|
|
|
// TODO: Maybe move this to the provider itself
|
|
|
|
set(this.provider, 'baseUrl', src);
|
2022-09-15 08:43:17 +00:00
|
|
|
return this.manager.open(OAUTH_PROVIDER_NAME, {}).catch((e) => {
|
2020-05-05 16:29:35 +00:00
|
|
|
let err;
|
|
|
|
switch (true) {
|
|
|
|
case e.message.startsWith('remote was closed'):
|
|
|
|
err = new Error('Remote was closed');
|
|
|
|
err.statusCode = 499;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
err = new Error(e.message);
|
|
|
|
err.statusCode = 500;
|
|
|
|
}
|
|
|
|
this.store.adapterFor(this.getModelName()).error(err);
|
|
|
|
});
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
}
|