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
Athens currently supports a couple of types of authentication:
Basic Authentication: authenticates clients to the Athens server itself. If the user has the basic auth, then he/she can access the Athens server.
.netrc file: authenticates Athens with upstream modules. This is so that Athens can download and store private modules.
I propose implementing a third option:
Propagated Authentication: This will allow Athens to accept an Authorization header. However, it will not check it against a static username/password. Instead, it will dynamically create a .netrc file with the given authentication and with machine set to the requested module hostname.
This will allow Go developers to provide their own identity for Athens which will then allow them access to their own private modules.
There are a few things to be aware of:
go mod download can only implicitly authenticate with git-clones through the .netrc file in the HOME directory. So we'd have to dynamically create/destroy home dirs for every go mod download that carries an Auth header. If there is enough demand, we can provide a feature in the future that copies certain files from HOME to TempHome (i.e. .gitconfig)
Once a Module is retrieved and stored, Athens won't know if the next user who requests it is actually authorized to access it or not. This can be solved by providing a ValidationHook or putting Athens behind an auth proxy that can authorize a auth header against the requested module. Note that a ValidationHook at the moment does not include list/latest, so a proxy is likely more appropriate.
The text was updated successfully, but these errors were encountered:
Athens currently supports a couple of types of authentication:
Basic Authentication: authenticates clients to the Athens server itself. If the user has the basic auth, then he/she can access the Athens server.
.netrc file: authenticates Athens with upstream modules. This is so that Athens can download and store private modules.
I propose implementing a third option:
Propagated Authentication: This will allow Athens to accept an Authorization header. However, it will not check it against a static username/password. Instead, it will dynamically create a
.netrc
file with the given authentication and withmachine
set to the requested module hostname.This will allow Go developers to provide their own identity for Athens which will then allow them access to their own private modules.
There are a few things to be aware of:
go mod download
can only implicitly authenticate with git-clones through the .netrc file in the HOME directory. So we'd have to dynamically create/destroy home dirs for every go mod download that carries an Auth header. If there is enough demand, we can provide a feature in the future that copies certain files from HOME to TempHome (i.e. .gitconfig)Once a Module is retrieved and stored, Athens won't know if the next user who requests it is actually authorized to access it or not. This can be solved by providing a ValidationHook or putting Athens behind an auth proxy that can authorize a auth header against the requested module. Note that a ValidationHook at the moment does not include list/latest, so a proxy is likely more appropriate.
The text was updated successfully, but these errors were encountered: