[emelialei88]

Summary

This PR adds support for authentication credential callbacks in the BlazingMQ Python SDK, enabling applications to provide dynamic authentication credentials when connecting to secured brokers.

New API Components

• BasicAuthnCredentialCb - Python wrapper class that accepts a callable returning (mechanism: str, data: bytes) or None
• FakeAuthnCredentialCb - Cython class that bridges Python callbacks to C++ authentication infrastructure
• authn_credential_cb parameter added to Session.__init__() and Session.with_options()

Implementation Details

• Integrated C++ authentication callback infrastructure with Python callable interface
• Implemented proper GIL management for cross-language callback invocation
• Added support for passing authentication credentials from Python to C++ BlazingMQ SDK
• Exposed get_credential_data() method for C++ to invoke Python callbacks

Example Usage

import blazingmq

def main() -> None:
    session = blazingmq.Session(
        blazingmq.session_events.log_session_event,
        authn_credential_cb=lambda: ("BASIC", b"python:sdk")
    ...

[678098]

Looks good, just a few comments

[678098]

We might log mechanism on the broker.
Not sure if we want to allow every possible character there
https://github.com/bloomberg/blazingmq/pull/1776/changes

[pniedzielski]

This is a good point. I have three thoughts:

• C++ and Java SDKs don't seem to do any validation on this front. We probably should. If the C++ SDK did validation we would get it here "for free" (though we may still want to do it in pure Python to get a nicer error message). Whatever we do, we should probably do it everywhere.
• Here, I think this test is probably still worthwhile, because it checks a Cython type conversion, which can silently drop anything after the NUL byte. Unless we validate and reject in pure Python that's still going to be a possibility.
• Broker should also validate, I think, from the wire, from the config, and from the plugin.

I'm not sure exactly what the limits should be, though. Maybe it's okay for now to encode the string on the broker just before logging it? What are your thoughts on this?

[678098]

What do you mean by "encode" in this context? Sanitize the string by replacing non-readable characters with ? as we do now?
We can perform the check in SDK then.