Hi,
Adding t.conch's ssh manhole (any third party IUsernamePassword provider
would've done, really) to my app recently uncovered some unicode handling
issues and I'm wondering what the appropriate way to resolve them is.
In my API (AMP) there is a:
- e-mail which is unicode
- password which is unicode
In my store (Axiom), there is a:
- uid (unique user identifier, think UUID) which is bytes
- e-mail which is unicode
- password which is bytes, because it's the output of scrypt. scrypt also
takes bytes as input: the password is first utf-8 encoded.
Previously I was mistakenly handing around IUsernamePasswords where the e-mail
address was unicode.
Obviously the ICredentialsChecker implementation should take IUsernamePasswords
that actually satisfy their contract and don't just pretend to, so ALL
credentials it receives should have str/str, no exceptions. So, right now my
credentials checker decodes the provided username to unicode in order to find
the user by e-mail address (since, as mentioned above, Axiom thinks my e-mail
addresses are unicode).
The flip side of this is that the login method now first encodes the provided
username and password as unicode. This is at least a semantically correct
solution, but has the somewhat surprising property that in the 99.9% use case,
the e-mail is received as unicode, immediately encoded, and then virtually
straight after decoded again. That doesn't mean it's wrong, but it's a little
weird.
Potential solutions:
1. Make e-mail addresses bytes always. I don't know if this is semantically
valid.
2. Add an IUnicodeUsernamePassword interface and implementation, and leaving
adaptation to handle decoding/encoding. The downside here is that IIUC cred
does not try to adapt to the ICredentialsChecker's supported interfaces,
something I believe I complained about a few years back.
cheers
lvh
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
