Support custom encoding for basic auth credentials

[kxepal]

This introduces BasicAuthEx namedtuple which acts as like as BasicAuth
one with single exception as it handles encoding as third argument.

RFC2617, section 2 (HTTP Authentication) defines basic-credentials:

basic-credentials = base64-user-pass
base64-user-pass  = <base64 encoding of user-pass,
                     except not limited to 76 char/line>
user-pass         = userid ":" password
userid            = *<TEXT excluding ":">
password          = *TEXT

RFC 2616, section 2.1 defines TEXT to have ISO-8859-1 encoding
(aka latin1):

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than
ISO-8859-1 only when encoded according to the rules of RFC 2047.

In fact, I know no Basic Auth implementation which respects RFC 2047
for Basic Auth.

However, the truth of the real world is that the most major browsers
are already uses UTF-8 instead of ISO-8859-1 for the credentials as
like as any modern web services which allows non-ASCII login/password.

Also, there is the RFC draft which aims to handle the case when
credentials will optionally get always encoded with UTF-8:
http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01

While we should strictly follow common standards, we also need to handle
real world use cases. This change allows that and makes aiohttp ready
for further Basic Auth scheme standard update.

[asvetlov]

If you change auth please update proxy authorization for https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/connector.py#L279 also.

[kxepal]

Hm...I thought about, but was ensure that it relies on ClientRequest requirements for specified params. Anyway, thanks for spotting. Fixed.

[asvetlov]

Relax the check please

[kxepal]

ouch...not sure how did I miss that. thanks!

[asvetlov]

Done. Thanks!

[fafhrd91]

maybe we should make three element namedtuple, something like _BasicAuth.
and replace BasicAuth with function with default third parameter encoding. BasicAuth() function may return _BasicAuth tuple

[kxepal]

@fafhrd91 thought about it, but wasn't sure since it could break BC even more. If it's ok, should I submit PR?

[asvetlov]

I'm ok with both decisions.

[kxepal]

Btw, we can make not function wrapper around private class, but just class with optional third argument:

class BasicAuth(collections.namedtuple('BasicAuth', ['login', 'password', 'encoding'])):
    def __new__(cls, login, password, encoding='latin1'):
        return super().__new__(cls, login, password, encoding)

Would be much better. Such functions-wrappers around private classes in Python 2.x stdlib always annoys me.

UPDATE: code fix, didn't test

[fafhrd91]

@kxepal I like your solution!

[fafhrd91]

also this class can implement .encode() method.

[asvetlov]

+1

[kxepal]

also this class can implement .encode() method.

mmm...it will be only useful if we'll raise an exception instead of warning when non BasicAuth instance arrives like it happens for ProxyConnector.

[kxepal]

Anyway, created #112 for further discussion.

[kxepal]

Pingback with new RFC-7617 which defines optional charset parameter. And UTF-8 usage now legalized for user credentials encoding.

[asvetlov]

Good to know

[asvetlov]

Would do you open an issue for supporting charset param?

[kxepal]

Sure. Could even try to make a patch for it.

[kxepal]

Done: #540

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.