Message253287
Thanks, but special-casing login in the 'auth' method means that the auth method isn't working right, since special-casing defeats the whole purpose of the auth mechanism.
I think we need to change the logic in auth so that it is checking for a 334 even if it has been provided an initial response. That is, outdent the block that starts with the '# Server replies...' comment. Once that is done, auth_login becomes:
def auth_login(self, challenge=None)
if challenge is None:
return encode_base64(self.user.encode('ascii'))
else:
return self.password
We may also need to add a try/except around the base64.decodebytes in auth.
And we need a unit test that demonstrates the current failure.
I'm also wondering now about the ascii encoding on the challenge and response. Someone should check the RFC to see if those are limited to ascii or if they can contain other bytes. If they are limited to ascii we should stick in a comment to that effect with a pointer to the relevant RFC section. |
|
Date |
User |
Action |
Args |
2015-10-21 13:24:39 | r.david.murray | set | recipients:
+ r.david.murray, barry, merkel |
2015-10-21 13:24:39 | r.david.murray | set | messageid: <1445433879.55.0.936074435237.issue25446@psf.upfronthosting.co.za> |
2015-10-21 13:24:39 | r.david.murray | link | issue25446 messages |
2015-10-21 13:24:39 | r.david.murray | create | |
|