Closed
Bug 660089
Opened 14 years ago
Closed 14 years ago
unicode passwords are not authing correctly against sync in proxies
Categories
(Cloud Services :: Server: Core, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: telliott, Unassigned)
Details
Attachments
(1 file)
697 bytes,
patch
|
Details | Diff | Splinter Review |
if you have a unicode password and try to execute the purge data and delete account functions in a-p, everything works fine except for the remote sync calls which always fail.
Reporter | ||
Comment 1•14 years ago
|
||
I don't think this is a blocker. unicode passwords are currently not working at all on account-portal (they did in the past, so wtf?). Trying to log in gives me a dinosaur.
Reporter | ||
Comment 2•14 years ago
|
||
This gets weirder and weirder.
My apache header going into sync on stage:
Authorization=Basic enQyenE1ZTRmbWN4dnltNmU2ZDQ2dXpseWVsamtlY2k6dGVzdOkxMjM0
if (in python) you do
print 'enQyenE1ZTRmbWN4dnltNmU2ZDQ2dXpseWVsamtlY2k6dGVzdOkxMjM0'.decode('base64')
you get
zt2zq5e4fmcxvym6e6d46uzlyeljkeci:test?1234
instead of
zt2zq5e4fmcxvym6e6d46uzlyeljkeci:testé1234
There must be something in the headers that is causing apache/php to un-base64 that straight into unicode without a decode step
Comment 3•14 years ago
|
||
so it turns out PHP expects ISO889-15 encoded Basic Authentication Digests
We're keeping that encoding for now: https://hg.mozilla.org/services/server-core/rev/4616e8d1930d
Reporter | ||
Comment 4•14 years ago
|
||
I think this'd help across the board, especially as more places start to work with the password.
Attachment #536195 -
Flags: review?(tarek)
Comment 5•14 years ago
|
||
(In reply to comment #4)
> Created attachment 536195 [details] [diff] [review] [review]
> Adds a function to unicode-clean the password
>
> I think this'd help across the board, especially as more places start to
> work with the password.
I don't think this is going to help because it keeps the fuzziness about what "password" should be in our application, e.g. a unicode or str.
In other words, everywhere we will deal with passwords we will have to check the type of the value we get. That makes it a whole lot easier to do errors.
The best way to solve this problem is to document properly everywhere what type "password" needs to be and choose a unique type throughout our apps.
I propose that we keep it "password" a unicode everywhere, and that all the functions that need to encode it to a string use the utf-8 codec.
In term of changes it boils down to:
- making sure all input are correctly converted to unicode if needed. That's basically web controllers.
- If the password is given in a json body, it will be either unicode either str because that's how it works. In that case we need to decode it.
- if the password is provided in a POST, it'll be a unicode
- we should not have GET cases
- making sure all functions that have a password option accept only unicode and that this is clearly documented in their docstrings. Passing a string should raise an error.
Comment 6•14 years ago
|
||
What I've explained, explained in the python doc: http://docs.python.org/howto/unicode.html#tips-for-writing-unicode-aware-programs
more info about uni: http://docs.python.org/howto/unicode.html
Comment 7•14 years ago
|
||
see bug 659995
Reporter | ||
Comment 8•14 years ago
|
||
I think the last of the uni bugs went away now that the whole system is python. If we come across new ones, they should probably have new bugs.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•14 years ago
|
Attachment #536195 -
Flags: review?(tarek)
You need to log in
before you can comment on or make changes to this bug.
Description
•