trungn1992 / httplib2

Automatically exported from code.google.com/p/httplib2
0 stars 0 forks source link

option to force HTTP basic auth #130

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Although most web server do respond with a 401 when accessing a protected 
resource that requires HTTP basic auth, this behavior is not required by 
RFC2617. Therefore, an option to force httplib2 to use basic authentication 
would be a useful extension.

Original issue reported on code.google.com by michael.gruenewald@gmail.com on 10 Feb 2011 at 10:39

GoogleCodeExporter commented 8 years ago
Randomly sending your name and password to all web sites is a sure way to get 
them stolen. If you really want to do that you can manually add the 
Authorization: header to your request, but there's no way I would make that a 
part of the library proper.

Original comment by joe.gregorio@gmail.com on 11 Feb 2011 at 5:06

GoogleCodeExporter commented 8 years ago
I don't see your point in not making it part of the library, because I think, 
it would have no security implications at all:

If one uses the add_credentials method without the domain parameter, the 
library currently sends the credentials to all server which ask for it -- 
without any further restrictions or user-visible effects. On the other hand, if 
one uses the domain parameter, the library sends the credentials only to the 
servers with the correct host names. So your argument was, that 'randomly 
sending your name and password to all web sites is a sure way to get them 
stolen.' That wouldn't even be the case. The only difference would be, that a 
thief needs to ask the library for your password. So a thief needs to be stupid 
enough not to ask for it, but clever enough to store unrequested passwords. 
Also the application using the library would be be insecure anyway because it's 
not using the domain parameter.

I cannot see a risk here. I would guess, that other decisions like making the 
domain parameter optional are way more critical and result in considerable more 
insecure applications.

TL;DR: requiring a thief to silently ask for a password has nothing to do with 
security

Original comment by michael.gruenewald@gmail.com on 13 Feb 2011 at 6:41

GoogleCodeExporter commented 8 years ago
I'm in favor an option to actually send HTTP basic auth when you ask the 
library to do so.

First - requiring an extra HTTP request/response is just a waste.  I'd consider 
it bad form to do two HTTP requests when one will do.

Second - It isn't obvious at all, at least from these basic examples ( 
http://code.google.com/p/httplib2/wiki/Examples ) that this is how the library 
functions.  At best 'add_credentials' in a poor name, since it only optionally 
adds credentials.

Third - this relates to the second, I had a URL that required auth to do its 
job, but httplib2 was failing to do the right thing, despite my call to 
'add_credentials'.  After watching the request/response in more detail it 
became clear that httplib2 never sent the username/password I asked it to send 
because the server wasn't replying with 401.  That was wasted time trying to 
debug something copied directly from the httplib2 example code.

In response to the "Randomly sending your name and password to all web sites is 
a sure way to get them stolen" feedback.  Yes, you could code up a script that 
randomly sends your username/password to various sites on the web, but that 
seems like a very edge case.  Much more likely that you are going send them to 
a very specific site.

Original comment by jos...@josephscott.org on 16 May 2011 at 8:11

GoogleCodeExporter commented 8 years ago
re: "Randomly sending your name and password to all web sites is a sure way to 
get them stolen."

That's not what is happening here. This is a python library, not a web browser. 
When I ask the library to add credentials, it should do what I ask.

"I'm in favor an option to actually send HTTP basic auth when you ask the 
library to do so."

I couldn't agree more. This additional layer of overhead and latency is 
ridiculous - especially since most programmers will have absolutely no idea 
this will be happening in the background.

Original comment by jmanc...@gmail.com on 20 Jun 2012 at 5:50

GoogleCodeExporter commented 8 years ago
I'll also follow this up with a "yes please".

It's a shame you've marked this as invalid.

For parallels, see wget's --auth-no-challenge option.

Also, as pointed out above, the add_credentials option effectively means you're 
already disclosing the cached credentials to any site that presents a 401, 
unless you actively specify a domain.

In my case, I'm running into this using the jenkins REST API:

https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients

Original comment by cwith...@gmail.com on 31 Jan 2013 at 3:29

GoogleCodeExporter commented 8 years ago
There are two issues with this in the GitHub API:
-If you don't send authentication data, you're limited to 60 requests per hour, 
rather than 500.
-Requests regarding private repositories (and non-public settings on public 
ones) return 404 rather than 401 or 403 if you're not authorized, to prevent 
you from testing whether they exist.

I'm currently using urllib2 (thinking about porting to httplib2) and indeed 
adding the header by hand, as it has the same behavior.

Original comment by AI0...@gmail.com on 12 May 2013 at 2:53

GoogleCodeExporter commented 8 years ago
That's 5000 per hour, not 500.

Original comment by AI0...@gmail.com on 12 May 2013 at 3:02