auth-scheme missing from Authorization header when talking to registry

[sfackler]

We currently generate a header that looks like Authorization: asdfasdfasdfasdf:

cargo/src/crates-io/lib.rs

Line 172 in 868d373

headers.append(&format!("Authorization: {}", token))?;

This does not match up with the grammar specified in RFC 7235, however:

credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Authorization = credentials

[sfackler]

If we change this for crates.io, we should make sure to allow custom registry tokens to be formatted however the registry requires - Basic asdfasdfasdfsf or Bearer asdfasdfasdf for example.

[TimDiekmann]

Wouldn't this be a breaking change as custom registries already landed?

[dtretyakov]

@ehuss any updates on it? It seems that crates should follow standards.

What is your recommendation for custom registry vendors on that regard?

[dtretyakov]

Currently it's in

cargo/src/cargo/sources/registry/http_remote.rs

Line 591 in f1dadb6

headers.append(&format!("Authorization: {}", authorization))?;

[dtretyakov]

Could not it be addressed along with new sparse protocol?

cargo/src/cargo/sources/registry/http_remote.rs

Lines 571 to 574 in f1dadb6

	// Include a header to identify the protocol. This allows the server to
	// know that Cargo is attempting to use the sparse protocol.
	headers.append("cargo-protocol: version=1")?;
	headers.append("accept: text/plain")?;

[Eh2406]

There is basically no update.
The adherence to standards about the authorization header are lax in the real world. There are registries that require nonstandard authorization formats. The fact that cargo can send nonstandard authorization headers is a feature removing it would be a breaking change. It is also widely enough used that that breaking change is probably not going to happen. The confusing naming where the configuration token is in fact used as authorization header verbatim is unfortunate, but not easily changed.

Unfortunately the sparse protocol does not provide an opportunity for breaking changes, because the sparse protocol describes how to interact with the index and the authorization headers are currently sent to API endpoints. It is possible to have both indexes using GIT and sparse protocols that point to the same API endpoints.

There is also work about adding auth-required, which would allow sending the authorization headers to the index requests when using the sparse registry. So far that work is not included requiring compliance with the standards. Of course such a system would need some way to specify that you want to send a noncompliant header in case the registry needed that.

(P.S. you can edit your comments if you have more to add on the subject.)

[epage]

@arlosi wanted to check if any of the auth work affected this.

[arlosi]

@arlosi wanted to check if any of the auth work affected this.

No. This is basically a crates.io issue. The "token" is an Authorization header, so in order to be compliant, it should start with Bearer , Basic or similar. The naming "token" is a bit unfortunate and confusing.

3rd party registries usually document how to configure the token appropriately. Everything eh2406 said above is still current.

[Turbo87]

FWIW with rust-lang/crates.io#11350 crates.io now supports both empty and Bearer auth schemes (not deployed yet though)