krtek4 / MultiPass

Automatically login to Basic Authentication using data based on URL regexp.
http://gilles.crettenand.info/MultiPass
Do What The F*ck You Want To Public License
88 stars 23 forks source link

No HTTP_AUTHORIZATION header #42

Closed kbuilds closed 7 years ago

kbuilds commented 7 years ago

I am not receiving a header for HTTP_AUTHORIZATION in the request - a header that is used in many webservers and application frameworks.

It's also very possible that I am doing something stupid.

krtek4 commented 7 years ago

Hi there,

Are we speaking about the "Authorization" header that is supposed to be sent by your browser to respond the the basic auth challenge ? I imagine it is "renamed" to HTTP_AUTHORIZATION by the framework.

Can you describe what you are trying to do and how did you configure the extension to do so ?

kbuilds commented 7 years ago

I think that you're right, but for some reason, it seems that the JS application is encoding the basic credentials differently than other tools that I have used before (i.e. python requests)

I've looked at your code, as well as the code for requests, and it seems that both encode the credentials as base64 username:password, but I cant see any difference in the actual header itself.

https://github.com/kennethreitz/requests/blob/master/requests/auth.py#L66 vs https://github.com/krtek4/MultiPass/blob/master/js/extension.js#L75

However, in my framework (django), the header is not parsed into request.META["HTTP_AUTHORIZATION"] when using MiltiPass, but it is when using requests.

I'll continue digging on the serverside. Feel free to close this until I actually find the difference

krtek4 commented 7 years ago

Might it be that your server is not requesting for an authorization?

Two pre-requisites must be satisfied for the extension to send credentials:

  1. The server must request for an authentication
  2. The extension must have a regex configured that matched the hostname.

First point is managed by the browser directly, the extension is configured in such a way that it is called by the browser only when a page return the headers related to an authentication request. The way this really works is that a first request is made on the page. The server returns a 403 status code and only then Chrome ask the extension for credentials. If you have another mechanism in place to perform the authentication, it might be possible that it interferes with this process.

Second point can be checked in the extension popin, if a regex matched, it will be displayed in green. Or in yellow if there were multiple matches.

Also, be aware that for the first point, the browser won't ask for an authentication if it already happened once during this session, because the credentials are then kept in memory, so in order to test correctly you might need to restart your browser after each try.

kbuilds commented 7 years ago

1 is definitely the issue. The server is not returning a 403 when the use is not authenticated.

Thank you for your help with this. I'll close the issue.