authentication fails

[jcomeauictx]

something, I'm guessing the requests library, is turning the Authorization header from Bearer to Basic, which causes authentication to fail.
droplet.py.txt
droplet.log.txt

[jcomeauictx]

I have requests version 2.4.3

[jcomeauictx]

requests 2.7.0 no help either.

[koalalorenzo]

If it is a request problem, maybe we should open an issue there, instead of python-digitalocean
Can you confirm that this is a bug related to request? I had no time to test it. I will do it probably tomorrow.

[jcomeauictx]

I cannot confirm at this time. but since this bug makes the library unusable, wouldn't you want to know anyway, so you could code around the problem?

[koalalorenzo]

since this bug makes the library unusable, wouldn't you want to know anyway, so you could code around the problem?

OFC. That's why I will check tomorrow ;-) I suggest you to do the same!
I admit that request in past caused some errors because they changed the way they were using options for specific methods. I will check tomorrow after some sleep! ;-)

[jcomeauictx]

OK thanks.

[koalalorenzo]

It works fine for me, using also requests v 2.4.3
I am going to trigger some automatic tests to be sure that everything is fine.

I was reading your code without understanding what is happening. Are you sure that your code is not messing up with requests? Have you tried on another OS/Machine? So fare it does not seem a problem. If you find the bug, then feel free to re-open the issue 👍

[fjarlq]

I was hitting the same problem that @jcomeauictx originally reported: my Authorization header was being mysteriously transformed from Bearer into Basic.

I was baffled until I searched for "Basic" in the issues for the requests project, which turned up this recent bug report: psf/requests#3929

That was indeed my problem. I have this line in my $HOME/.netrc to enable automatic login for anonymous FTP:

default login anonymous password anonymous@

requests interprets that to mean it should always override the Authorization header with my .netrc default, even when the caller has explicitly provided an Authorization header.

According to a comment in that bug report, a requests core developer is amenable to changing this behavior in requests 3.0 so that when the caller sets Authorization it won't get overridden.

Until then, perhaps python-digitalocean should consider the advice of requests core developer @Lukasa:

"So it is quite possible that the library wrapping requests should be setting trust_env to False if it is handling headers itself."

Thoughts, @koalalorenzo? Thanks!