Support for bearer auth in .netrc

[porglezomp]

Previously the .netrc only handled authorization that contains both a username and password.

This is a divergence from the behavior of httpie.

This only activates when --auth-type bearer is specified without the --auth flag, so I believe it should be a compatible change. (I believe previously using it like this would have always reported an error?)

[porglezomp]

force-pushed to squash rustfmt fixes into the commits

[ducaale]

Thanks, @porglezomp. Can I double check which version of HTTPie was the .netrc working with --auth-type=bearer? In the latest version of HTTPie (v3.2.1), it doesn't seem that --auth can be left out, which is a prerequisite for using the .netrc file

$ cat .netrc
machine httpbin.org
password pass

$ http --version
3.2.1

$ http -v httpbin.org/json --auth-type bearer
usage:
    http [METHOD] URL [REQUEST_ITEM ...]

error:
    --auth required

for more information:
    run 'http --help' or visit https://httpie.io/docs/cli

[porglezomp]

This is specifically different behavior from httpie.
It's an enhancement to xh that I found useful, and I'm less confident about making the change on the httpie side.

I don't know how strict you're interested in the compatibility between xh and httpie being.
I personally felt alright making this change since it still leaves xh as a drop-in replacement (although not vice-versa).

This enhancement doesn't change behavior on any httpie command that currently works:

• if you don't explicitly request the --auth-type=bearer it won't act any differently
• existing commands using --auth-type=bearer (in scripts and things) would be passing --auth so it won't consult the .netrc for the token in those cases

This does cause xh to handle a new case.

[ducaale]

This enhancement doesn't change behavior on any httpie command that currently works:

• if you don't explicitly request the --auth-type=bearer it won't act any differently
• existing commands using --auth-type=bearer (in scripts and things) would be passing --auth so it won't consult the .netrc for the token in those cases

I am okay with supporting .netrc for bearer auth but I'm a little nervous about making the login field optional. Can you revert login to be required but ignore it when the auth type is bearer?

[blyxxyz]

Using netrc for this feels like a stretch, but I can't think of any failure scenarios or obviously better alternatives, so I think supporting this is for the best.

(We can't extend the format with a token directive, Python's netrc parser doesn't like that.)

In httpie/cli#1216 Jakub actually suggested this enhancement, so it's worth trying there as well, so I think it would be accepted in HTTPie.

[blyxxyz]

I didn't know about that attribute, this is great

[blyxxyz]

I am okay with supporting .netrc for bearer auth but I'm a little nervous about making the login field optional. Can you revert login to be required but ignore it when the auth type is bearer?

An optional login field seems fine as long as it's only optional for bearer auth, and when the password is a token there's no good value for login. So I think it's better this way.

Though HTTPie crashes if there's no login:

  File "[...]/httpie/cli/argparser.py", line 316, in _process_auth
    orig=SEPARATOR_CREDENTIALS.join(netrc_credentials)
TypeError: sequence item 0: expected str instance, NoneType found

[ducaale]

An optional login field seems fine as long as it's only optional for bearer auth, and when the password is a token there's no good value for login. So I think it's better this way.

@blyxxyz What if we require the login field to equal token when using bearer authentications? When I searched for .netrc + bearer auth, the only thing I could find was databricks which did it that way. See https://docs.databricks.com/dev-tools/api/latest/authentication.html#store-tokens-in-a-netrc-file-and-use-them-in-curl

[blyxxyz]

What if we require the login field to equal token when using bearer authentications? When I searched for .netrc + bearer auth, the only thing I could find was databricks which did it that way. See https://docs.databricks.com/dev-tools/api/latest/authentication.html#store-tokens-in-a-netrc-file-and-use-them-in-curl

That's a little unintuitive, I think we should ideally do it in a way that could be guessed without documentation. For databricks it's a hack to fit it into curl's existing netrc loader, but we're providing the netrc loader so we have more options.

Is there a drawback to an optional login field? It made me uneasy at first but after thinking through it it seems well-behaved.

[ducaale]

That's a little unintuitive, I think we should ideally do it in a way that could be guessed without documentation. For databricks it's a hack to fit it into curl's existing netrc loader, but we're providing the netrc loader so we have more options.

Sounds reasonable. Let's keep the login field optional 👍.

[blyxxyz]

Looks great!

Are you interested in pitching this to HTTPie?

[porglezomp]

My work situation means I'd need to get approval for that as a separate contribution, so I'm probably not the best person to pitch that at the moment 😔

[pwagland]

Looks great!

Are you interested in pitching this to HTTPie?

Pitched: httpie/cli#1569