Migrate to API tokens not tied to user accounts#1277
Conversation
GitHub Actions
Inactive
2a92a58 to
31261db
Compare
GitHub Actions
Inactive
|
|
||
| const cache = new NodeCache({ stdTTL: 5 * 60, checkperiod: 60 }); | ||
|
|
||
| const tokens = process.env.API_TOKENS?.split(",") || ["token"]; |
There was a problem hiding this comment.
Is the default of "token" really meaningful? Couldn't it be more confusing than e.g. using an empty list here as he default?
There was a problem hiding this comment.
Yeah the reason I added it is so that in your local development environment you wouldn't necessarily need to add anything in the .env file. But I'm also fine with doing it the other way.
There was a problem hiding this comment.
I think it's good to have it work without anything in .env, but at the same time I think we should not use a fake-token-string, but something that clearly "identifies" as invalid input for a token, like the empty string / array.
There was a problem hiding this comment.
So do you mean kind of bypassing this check in local development? So if the list is empty, just allow the request?
There was a problem hiding this comment.
I'm not sure 😄 Is there a chance that the request would succeed in this case? If so, then yes, just allowing the request for local development makes sense. If not, I'd just use empty default values, let the request fail hard, and maybe print / log a hint to the user / developer in this case that a token has to be provided.
There was a problem hiding this comment.
Yes, the request would succeed then.
31261db to
f1af9b7
Compare
GitHub Actions
Failure
GitHub Actions
Inactive
The API tokens that are used to authenticate access to getting scan results, adding jobs and getting package configurations, used to be personal tokens for all users. This is changed as there's a need for more restrictions to the access to these endpoints. As the number of needed tokens is low and it is expected that they rarely change, these tokens are added through an environment variable for simplicity and faster access. However, if the need emerges, `CRUD` support for token handling for server admins could be added later. The main motivation for this change comes from developing DOS alongside the ORT Server, and from an upcoming feature on DOS that will allow users to create their own clearance items. These clearance items will be linked to the organization the user belongs in, and for example the package configurations endpoint will support returning clearance items based on an organization ID, and so the need to restrict access to this endpoint is vital, as users shouldn't be allowed to access clearance items on other organizations than their own. Signed-off-by: Johanna Lamppu <johanna.lamppu@doubleopen.org>
As the API tokens won't be personal tokens anymore, remove the logic to add and edit them. Signed-off-by: Johanna Lamppu <johanna.lamppu@doubleopen.org>
f1af9b7 to
44ad4cf
Compare
GitHub Actions
Inactive
2 participants
In the early development, the DOS API was used with ORT from the CLI, and so the access to the endpoints that ORT uses was authenticated with a personal access token, that each user could get through the UI. Now that ORT Server has changed things quite a bit, there is really only a need for one token that the ORT Server holds, and the only other tokens that are needed are for developers.
There is an upcoming feature, where users will be able to make their own clearance items, and these clearance items will be accessible to the users in the same organization they were created for. This causes a need to change the implementation of the package configurations endpoint, so that it will return clearance items based on an organization ID. It is possible to keep the current authentication method, but a stricter access to the endpoint will make things a bit simpler on the API side.
Another small quite unlikely but also quite an important protection that this change brings, is not allowing users to add jobs straight through the API, which would prevent the edge-case where a malicious user could potentially add some garbage data to DOS.
Also after this change, there won't be a need to have a fake user for the purpose of managing the ORT Server DOS API token.
Please see the individual commit messages for details.