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 vinay.sajip
Recipients Arfrever, ncoghlan, vinay.sajip
Date 2012-07-29.17:39:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343583577.75.0.0346960628807.issue15452@psf.upfronthosting.co.za>
In-reply-to
Content
> As far as your other suggestion goes, don't reinvent crypto badly -
> if you want to provide authentication support in listener(), provide a
> hook that allows the application to decide whether or not to accept
> the configuration before it gets applied.

Well, that's fine. My earlier suggestion keeps the API change to a minimum, but I suppose there's no real need to be so minimal.

I suppose the basic approach would be to pass to listen() an optional verify callable (defaulting to None) which, if provided, would be called with the bytes received over the socket. That allows for e.g. signed or encrypted data. The value returned from the verify() call would be processed as the current received value is (allowing the verifier to transform the input, e.g. by decrypting it).
History
Date User Action Args
2012-07-29 17:39:37vinay.sajipsetrecipients: + vinay.sajip, ncoghlan, Arfrever
2012-07-29 17:39:37vinay.sajipsetmessageid: <1343583577.75.0.0346960628807.issue15452@psf.upfronthosting.co.za>
2012-07-29 17:39:37vinay.sajiplinkissue15452 messages
2012-07-29 17:39:36vinay.sajipcreate