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)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: telliott, Unassigned)

Details

Attachments

(1 file)

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.
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.
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
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
I think this'd help across the board, especially as more places start to work with the password.
Attachment #536195 - Flags: review?(tarek)
(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.
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
Attachment #536195 - Flags: review?(tarek)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: