Bonjour,
A user is a developer and they have accounts on multiple forges, either because they created them or because fedeproxy did on their behalf. Assuming a fedeproxy instance is responsible for a single forge, the internal representation of a user is:
- the emails
- the username
- the password
- the API token that fedeproxy obtained to act on behalf of the user
If fedeproxy has root access to the forge, this information is obtained without any action from the user. If fedeproxy does not have root access, the user needs to provide a token to fedeproxy as a first step (see this example).
Since fedeproxy is stateless, the token is stored on disk during a few weeks when fedeproxy does not have root access to the forge. Otherwise the users would be forced to renew the token whenever the fedeproxy service is restarted.
For a given software project, it is assumed the user will use a single forge (let’s call it the primary forge). But fedeproxy will need to obtain credentials (user/password or token) for each forge where it needs to act on behalf of the user. Since fedeproxy is stateless and this information needs to be preserved, it is stored in a private project of the primary forge. When fedeproxy needs access to another forge, it can retrieve the credentials (user/password or token) from this private repository.
An issue can be created by fedeproxy in the private repository of the primary forge whenever its token is about to expire as a reminder for the user that it needs to renew it, with a link to the page where OAuth2 will obtain authorization.
The private repository is encrypted with the private key of the fedeproxy instance that created the repository. An issue is created every month with a link valid 24h from which the user can download a decrypted version of the repository for safe keeping on their local machine. When a user migrates to another forge, the content of the repository is encrypted by the source fedeproxy instance with the public key of the destination fedeproxy instance.
Cheers