The ultimate goal of this pull-request is to provide a way for users of the library to create their own SASL mechanisms that would reply to complex challenge/response scenarios.
The first commit only to show the direction I'm suggesting and maybe get some early feedback (I fully intend to write more tests if this direction is approved):
Separate SASL_PLAIN and SASL_ANONYMOUS handlers in their own classes and use them from the main Sasl object.
add a saslHandler field to the connect policy that would allow a user to pass a custom Sasl challenge/response handler.
the new classes use async methods because in the case of the sasl challenge/response scenario, there are cases where the code computing the response to the challenge will be asynchronous.
One thing that bothers me is that the SASL objects right now manipulate frames which are believe are not exported from the library - we could change that to only manipulate buffers though, or decide to extract the frame objects.
The last option would be to accept implementation of custom SASL mechanisms in the repository of course.
The ultimate goal of this pull-request is to provide a way for users of the library to create their own SASL mechanisms that would reply to complex challenge/response scenarios.
The first commit only to show the direction I'm suggesting and maybe get some early feedback (I fully intend to write more tests if this direction is approved):
Sasl
object.saslHandler
field to the connect policy that would allow a user to pass a custom Sasl challenge/response handler.One thing that bothers me is that the SASL objects right now manipulate frames which are believe are not exported from the library - we could change that to only manipulate buffers though, or decide to extract the frame objects.
The last option would be to accept implementation of custom SASL mechanisms in the repository of course.
This change is