This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients barry, merkel, r.david.murray
Date 2015-10-21.13:24:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445433879.55.0.936074435237.issue25446@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-10-21 13:24:39r.david.murraysetrecipients: + r.david.murray, barry, merkel
2015-10-21 13:24:39r.david.murraysetmessageid: <1445433879.55.0.936074435237.issue25446@psf.upfronthosting.co.za>
2015-10-21 13:24:39r.david.murraylinkissue25446 messages
2015-10-21 13:24:39r.david.murraycreate