Skip to content

Support custom encoding for basic auth credentials#110

Merged
asvetlov merged 1 commit intoaio-libs:masterfrom
kxepal:basic-auth-encoding
Jul 8, 2014
Merged

Support custom encoding for basic auth credentials#110
asvetlov merged 1 commit intoaio-libs:masterfrom
kxepal:basic-auth-encoding

Conversation

@kxepal
Copy link
Copy Markdown
Member

@kxepal kxepal commented Jul 8, 2014

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
Copy link
Copy Markdown
Member

asvetlov commented Jul 8, 2014

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

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Jul 8, 2014

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

asvetlov
asvetlov reviewed Jul 8, 2014
View reviewed changes
aiohttp/client.py
Copy link
Copy Markdown
Member

@asvetlov asvetlov Jul 8, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relax the check please

Copy link
Copy Markdown
Member Author

@kxepal kxepal Jul 8, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@kxepal
Support custom encoding for basic auth credentials
555c35a 
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 asvetlov merged commit 555c35a into aio-libs:master Jul 8, 2014
@asvetlov
Copy link
Copy Markdown
Member

asvetlov commented Jul 8, 2014

Done. Thanks!

@fafhrd91
Copy link
Copy Markdown
Member

fafhrd91 commented Jul 8, 2014

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
Copy link
Copy Markdown
Member Author

kxepal commented Jul 8, 2014

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

@asvetlov
Copy link
Copy Markdown
Member

asvetlov commented Jul 8, 2014

I'm ok with both decisions.

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Jul 8, 2014

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
Copy link
Copy Markdown
Member

fafhrd91 commented Jul 8, 2014

@kxepal I like your solution!

@fafhrd91
Copy link
Copy Markdown
Member

fafhrd91 commented Jul 8, 2014

also this class can implement .encode() method.

@asvetlov
Copy link
Copy Markdown
Member

asvetlov commented Jul 8, 2014

+1

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Jul 8, 2014

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
Copy link
Copy Markdown
Member Author

kxepal commented Jul 8, 2014

Anyway, created #112 for further discussion.

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Oct 1, 2015

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

@asvetlov
Copy link
Copy Markdown
Member

asvetlov commented Oct 1, 2015

Good to know

@asvetlov
Copy link
Copy Markdown
Member

asvetlov commented Oct 1, 2015

Would do you open an issue for supporting charset param?

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Oct 1, 2015

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

@kxepal
Copy link
Copy Markdown
Member Author

kxepal commented Oct 1, 2015

Done: #540

@lock
Copy link
Copy Markdown

lock bot commented Oct 30, 2019

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.

@lock lock bot added the outdated label Oct 30, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

No reviews

Assignees

No one assigned

Labels

outdated

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kxepal @asvetlov @fafhrd91