You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We introduced build API keys in order to improve security inside builders, so instead of having one single key with access to all projects via the API, we generate one temporary key valid just for one project for each build.
That's definitely better than one global key, but this key still grants access to any version of that project, since builds are attached to one version, we should scope it just to that version. For example, if a build from a PR manages to leak the build API key, it will be able to interact with all the versions.
Describe the solution you'd like
Instead of attaching build API keys to a project, they should be attached to a build (after all they are named build api keys, not project api key :D).
API key for securely interacting with the API from the builders.
The key is attached to a single project,
it can be used to have write access to the API V2.
"""
project=models.ForeignKey(
Project,
on_delete=models.CASCADE,
related_name="build_api_keys",
help_text=_("Project that this API key grants access to"),
)
We may be tempted to just add a "version" field, but that has the downside of being able to interact with all the builds linked to that version, again, we want that key to be the more scoped possible.
Additional context
I think I decided to link the keys to a project since we make use of some APIs that update or retrieve some information about the project, while that's a valid use case, they should be special cases that only grant limited access to resources of the project.
The text was updated successfully, but these errors were encountered:
What's the problem this feature will solve?
We introduced build API keys in order to improve security inside builders, so instead of having one single key with access to all projects via the API, we generate one temporary key valid just for one project for each build.
That's definitely better than one global key, but this key still grants access to any version of that project, since builds are attached to one version, we should scope it just to that version. For example, if a build from a PR manages to leak the build API key, it will be able to interact with all the versions.
Describe the solution you'd like
Instead of attaching build API keys to a project, they should be attached to a build (after all they are named build api keys, not project api key :D).
readthedocs.org/readthedocs/api/v2/models.py
Lines 31 to 45 in 77758cd
We may be tempted to just add a "version" field, but that has the downside of being able to interact with all the builds linked to that version, again, we want that key to be the more scoped possible.
Additional context
I think I decided to link the keys to a project since we make use of some APIs that update or retrieve some information about the project, while that's a valid use case, they should be special cases that only grant limited access to resources of the project.
The text was updated successfully, but these errors were encountered: