Project key ownership

[vlada-dudr]

Is your feature request related to a problem? Please describe. As admin, or maybe project manager I would like to see all issued project tokens, so I can easily revoke them in case of leak. Also generally I don't think project keys should be bound to users, as they are generally used by applications or automations and there is no inherent owner of such key. More likely such key represents "bot" account or something similar.

Describe the solution you'd like unbound project keys from users and let them be managed by user privileged enough

Describe alternatives you've considered nothing comes to my mind

[Anty0]

Hi! Thanks for the report! Security and permissions management. The never-ending story ^^

It makes sense to have a way to manage and revoke keys on the admin side. Server admins can already do that technically, but there isn't an overview page for all project API keys within the organization—it might be a good addition.

Allowing organization owners to manage project API keys wouldn't solve the issue, though. Users can have personal access keys that grant access to all projects and organizations, and it wouldn't make sense for the organization owner to manage API keys that users might be using to access multiple organizations.

It might make sense to have this functionality for SSO (managed organizations) since, in that case, the organization manages users. We would then be able to show the organization owner all the API keys—both personal and project keys.

Regarding key ownership, currently, Tolgee in-context editing and other features depend on users generating their own API keys to log in. Developers need the API key to use in-context features when running a local deployment on their machine, while translators need it to log in to the browser extension and enable in-context translations for the production website. It makes sense for them to generate API keys under their own names. We plan to implement OAuth login for the browser plugin eventually, but even then, developers will still need API keys.

What is your use case or reasoning behind the feature request? Do you self-host Tolgee and need the feature for better instance management, or do you have an organization on Tolgee Cloud and would like to manage API keys for your organization?

[vlada-dudr]

Hi,

we self host and the thing is that we might delete/disable some developer accounts as they come and go, but that would likely destroy all tokens such users created. We are using the api key in CI pipeline so that essentially means that departure of such guy means rendering pipeline broken. Well, we of course should plan for this, we might create an "token user" or some other workaround. But, it is very easy to overlook that we cannot safely delete/disable certain users. I'd like to think anout project api keys in similar way GitLab treats Deploy Tokens - they are just bound to project (or group) and everybody with sufficient privileges can view, delete or add them.

[vlada-dudr]

in-context editing and other features depend on users generating their own API keys to log in. Developers need the API key to use in-context features when running a local deployment on their machine, while translators need it to log in to the browser extension

Shouldn't they use Personal Tokens for such tasks? That would leave Project Tokens for bots or automation, which are not really owned by single user.

[Anty0]

Thank you for your reply. I understand. It makes sense in a way. Not sure we'll implement something like that, though. Using the "token user" seems like the best option for now.

---

Shouldn't they use Personal Tokens for such tasks?

They can, but personal tokens always have all the user's permissions. I prefer using project tokens because I can restrict what they can be used for, but it's fine if they use personal tokens.

[Anty0]

I like, though, the idea of an admin page for the API keys a user has. Or maybe a shortcut to view them, to make it easier for the server admin to check.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.