CherryPy will allways decode basic authentication information with ISO-8859-1 #1680
Comments
@PJaros thanks for the detailed analysis. This needs some investigation, but I'd guess that the solution might need to be submitted to cheroot (just a note for now). |
I've been trying to create a PR. I've was able to pin-point where in cherrypy to make that happen but can't anticipate where this would fit in cheroot. I'm halting my work on the PR because:
If you wish so I can go into more details about the PR and the findings with the above mentioned problems. But as of right now i'll just pause my efforts right here. |
It would be useful if you could point certain places in code, because I haven't found them yet. |
Okay. I'll wrap-up my current findings tomorrow. |
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
I've wrapped it up with this Pull-Request here: #1684 which isn't complete either (it doesn't work with Python2.7). I'll invest some time later to understand your #1683 and try improving my PR. This is my very first attempt dealing with all this so .. please bear with me :) As a personal note to myself l'll try to move away from Basic Auth: The specs are pretty much broken by design. :P |
@PJaros it looks you're right: Firefox sends garbage in case of unicode creds :( |
|
|
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
I've only quickly skimmed this issue, but I saw the references to Firefox and password encoding. In my past experience, I've discovered that Firefox does not support non-ascii characters in passwords for basic auth (underlying issue here). We ended up not supporting non-ascii passwords at our organization for this reason. |
Is there something I can do to help to close this issue? |
@PJaros While working on it I've noticed tool duplication (#1688), so currently we're finally deprecating outdated one (#1689). |
(okay, it's probably all on github already) |
I'm getting pressure from my supriors to fix the issue... please. I understand that you wish to tiedy up your code first. But come on. I'm going to be forced to switch to a different framework and rewrite my code because of this issue :-( |
I'll try to that WIP PR. Ref: https://groups.google.com/d/msg/cherrypy-users/oBldDysSi7M/IvMNFHoyCwAJ |
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
This is a silly fix, which should evolve into one taking into account RFC7617. Ref #1680
I was able to test 14.2.0 7 days ago and everything works. Thanks for release this version. |
I have submitted the observed behavior on stackoverflow.
Issuing
curl -u 'curl:€öäü' -i -X GET http://10.25.5.17:8080/
will print
realm: 'MY_REALM', username: 'curl'-'63 75 72 6c', password: 'â\x82¬Ã¶Ã¤Ã¼'-'e2 82 ac c3 b6 c3 a4 c3 bc'
on the python console.
RFC-7617 explains how encoding should be handled concerning basic authentication.
Currently CherryPy doesn't offer a way to indicate what encoding scheme it wants and how it decodes it. Right now browsers will use different charsets:
On Redhat 6
On Windows 10 Version 1709
A possible solution would be if CherryPy would send
WWW-Authenticate: Basic realm="foo", charset="UTF-8"
and decode the authentication string as utf-8 instead of ISO-8851-1. But I'm sure that some other things might need to be considered. And I haven't tested if Firefox will switch to UTF-8 with this header.The text was updated successfully, but these errors were encountered: