Skip to content

Latest commit

 

History

History
117 lines (99 loc) · 4.27 KB

2019-05-01-http-auth.md

File metadata and controls

117 lines (99 loc) · 4.27 KB
Raw
created last updated status title authors
2019-05-01
2019-05-01
To be reviewed
Enable authoritative http downloads using .netrc
genrym

Abstract

This document describes an extension of the SkylarkRepositoryContextApi.downladAndExtract to enable HTTP downloads which require authorization, using the .netrc file specification as storage for the credentials.

Background

Currently, when using the rule http_archive for specifying a download, it is possible to download any anonymously open url. However, if the url requires Authorization for the download (be it Basic Authentication, OAuth2,...) - there is no such option. Such an example can be download a source zip from private github repository.

Proposal

We can use the .netrc file to store credentials for Authorization per host / domain.

Example of .netrc file contents:

machine github.com password my-auth-token
machine basic-auth.com login myuser password my-password

For token based authentication, we can use the password field to specify the authorization token / API key.

We will add the following properties to http_archive rule and SkylarkRepositoryContextApi.downloadAndExtract:

  • netrc_file_path : String
    • the location of the .netrc file. Default location for the .netrc file will be the user home directory, e.g. /Users/<username>/.netrc
  • netrc_domain_auth_types : SkylarkDict
    • mapping between a domain / host (which correlates to the .netrc file definition) to authorization type, e.g. Basic Authentication, OAuth2, custom prefix. Default will be an empty dictionary.
    • we use a mapping here to allow different hosts / domains as sources for the same file, which might have different authorization protocols / credentials

Example of http_archive rule definition:

http_archive(
    name = 'somefile',
    url = 'https://basic-auth.com/somefile.zip',
    sha256 = '87569EEA3732D8A11DCFC8293D08A443D79CE34CD4996822DD3D26F8F46ECEE0',
    type = 'zip',
    netrc_file_path = '/Users/user/.netrc',
    netrc_domain_auth_types = {
      "basic-auth.com": "basic"
    },
)

The result will be, that the http call will be sent with Authorization header with the value Basic base64(login:password), specifically in this case, given the .netrc file example above: Basic bXl1c2VyOm15LXBhc3N3b3Jk, according to rfc2617

Authorization Type Format

In order to support various authorization protocols which might also require some custom properties, e.g. a custom prefix protocol, which requires the prefix to be supplied as additional parameter to the authorization protocol definition, we can define the following format for the authorization type value, where the additional properties are optional:

Alt.1

<type>[:<prop1>=<val1>,<prop2>=<val2>,...]

Using the .netrc file example definition above, the defintion of http_archive rule will look like the following for custom prefix protocol. Taking github as example, which uses a non-standard authorization protocol:

http_archive(
    name = 'somefile',
    url = 'https://www.github.com/.../somefile.zip',
    sha256 = '87569EEA3732D8A11DCFC8293D08A443D79CE34CD4996822DD3D26F8F46ECEE0',
    type = 'zip',
    netrc_file_path = '/Users/user/.netrc',
    netrc_domain_auth_types = {
      "github.com": "custom_prefix:prefix=token"
    },
)

The result will be, that the http call will be sent with Authorization header with the value token my-auth-token.

Alt.2:

{
   "type": "<type>",
   "props": {
      "<prop1>": "<val1>",
      "<prop2>": "<val2>",
      ...
   }
}

Not sure whether it can be achievable with the SkylarkDict type:

http_archive(
    name = 'somefile',
    url = 'https://www.github.com/.../somefile.zip',
    sha256 = '87569EEA3732D8A11DCFC8293D08A443D79CE34CD4996822DD3D26F8F46ECEE0',
    type = 'zip',
    netrc_file_path = '/Users/user/.netrc',
    netrc_domain_auth_types = {
      "github.com": {
         "type": "custom_prefix",
         "props": {
            "prefix": "token"
         }
      }
    },
)

Backward-compatibility

The new configuration will be used only if explicitly defined per specific host / domain, thus is backward compatible.