This PR adds the possibility for mechanism classes dynamically decline being selected for client authentication.
In principle, the mere existence of a mechanism-defining module in combination with availability on the server, means the mechanism will be considered available for use by Authen::SASL::Perl. The _secflags check allows mechanism classes to refine that selection based on the security requirement flags passed by the client. However, some mechanisms may be available only when the caller provides additional data. One such example is SCRAM-SHA-1-PLUS, which authenticates with channel binding. As part of my SCRAM SASL bindings, I'm looking to implement the channel binding variant as well. Hence my request for inclusion of this PR. If you have better ways, please let me know.
This PR adds the possibility for mechanism classes dynamically decline being selected for client authentication.
In principle, the mere existence of a mechanism-defining module in combination with availability on the server, means the mechanism will be considered available for use by
Authen::SASL::Perl. The _secflags check allows mechanism classes to refine that selection based on the security requirement flags passed by the client. However, some mechanisms may be available only when the caller provides additional data. One such example is SCRAM-SHA-1-PLUS, which authenticates with channel binding. As part of my SCRAM SASL bindings, I'm looking to implement the channel binding variant as well. Hence my request for inclusion of this PR. If you have better ways, please let me know.