Description
Currently, the following gems duplicate partial support for a small subset of SASL mechanisms:
- net-imap
- net-smtp
- net-pop (it's actually missing, but it should be in there)
- net-ldap
- blather (XMPP)
- memcached
- dalli (another memcached client)
- ...and probably many others.
This duplication and incomplete support basically defeats the purpose of SASL. It seems to me that SASL is used in a wide enough number of internet protocols that some level of SASL support should be in stdlib. See e.g. it's in java standard edition
We could start with a very simple API, which only handles client-side authentication and doesn't do much more than Net::IMAP already does. Simply providing a standard for pluggable support is useful. E.g here's a starter proposal:
class Net::SASL::Registryto allow non-global config, so e.g. a mechanism could be added toNet::IMAPwithout affecting other libraries.#add_authenticator(name, mechanism_class)#authenticator(name, *args)- both of these methods would also be available from a global registry on
Net::SASL
Net::SASL::Authenticatorinterface (can provide a super-class withNotImplementedErroronperform):#initialize(*credentials, uri: nil)- some mechanisms require the host and port, and supporting that in the generic interface simplifies making clients work properly regardless of which mechanism is selected.
#supports_initial_response?#process(challenge)- just as withNet::IMAP. IR sends anilchallenge#done?- for mechanisms implementing a state machine, users of the library can know it is done without needing to call#performand catch an exception.respond_to?(...)could be used for backwards compatibility with Net::IMAP authenticators which haven't yet been updated to addsupports_initial_response?or#done?.
- utility methods:
Net::SASL.saslprep(string)- implements RFC4013, which is required by some mechanisms and recommended for others
And, of course, we could start by adding the existing Net::IMAP mechanisms. But it would be simple and very useful to add OAUTHBEARER and some others as well.
I've marked #22 as a draft, pending some discussion about this. Is this the correct place to discuss this? Should I create a ticket in the ruby issue tracker?