It might be worth adding that the Proton C++ examples *include* an
example that talks to Azure Service Bus (called service_bus.cpp). As
far as I know this example still works, so could be used as a template
to write client code that talks to Azure Service Bus.
Andrew
On Tue, 2022-08-09 at 09:22 +0100, Robbie Gemmell wrote:
> Ah yes, I forgot about that other SASL issue with EXTERNAL; due to a
> historic misunderstanding of how EXTERNAL works, the Azure services
> erroneously offer clients EXTERNAL in cases they should not.
> Naturally
> with it having been offered, clients supporting it may then pick
> it...but ultimately find it then doesnt work as expected, and they
> really should not actually have been offered it.
>
> On Mon, 8 Aug 2022 at 20:03, Zaq Rizer <idhindsi...@gmail.com> wrote:
> >
> > Thank you for the detailed information. I stumbled upon the
> > PN_TRACE_FRM
> > elsewhere online and had a realization after reading someone's
> > Python code
> > that indeed what you are stating is the truth; it was all related
> > to the
> > SAS mechanism. Examples/simple_send defaults to the EXTERNAL SASL
> > mechanism. Merely instantiating the connection_options with
> > .sasl_allowed_mechs("PLAIN") resulted in successful communication
> > with
> > Azure Event Hubs. Hopefully this conversation finds someone useful
> > in the
> > future.
> >
> > FYI, providing the user credentials in the URI (e.g.
> > "amqps://{user}:{password}@{host}") in c++ *does* work.
> >
> > Best,
> > Zaq
> >
> > On Mon, Aug 8, 2022 at 5:55 AM Robbie Gemmell
> > <robbie.gemm...@gmail.com>
> > wrote:
> >
> > > I wouldnt be so quick to rule out the 'send claims are required
> > > bit'
> > > as a red herring, it seems likely to be your main issue.
> > >
> > > The azure python client is likely using the CBS 'claims based
> > > security' setup that Microsofts bits use, where it either 'logs
> > > in'
> > > using ANONYMOUS and then sends structured claims-messages to the
> > > $cbs
> > > special address before actually then performing your messaging
> > > work,
> > > or 'logs in' using a CBS-related SASL mechanism. The Proton
> > > client is
> > > almost certainly not doing either of these as it doesnt know
> > > about
> > > either (unless you are doing the legwork to do the former
> > > yourself).
> > > If the Proton client similarly goes in using ANONYMOUS, but then
> > > doesnt do the $cbs dancing, it naturally wont have
> > > claims/permissions
> > > to send and thus wont be able to when it tries as you have asked
> > > it.
> > >
> > > Make sure you are passing any user and password via the
> > > connection
> > > options (
> > > https://qpid.apache.org/releases/qpid-proton-0.37.0/proton/cpp/api/classproton_1_1connection__options.html
> > > ).
> > > I'm not sure that its supported passing them via the URI in the
> > > C++
> > > binding. You might even need to further restrict the SASL
> > > mechanisms
> > > allowed to have it use PLAIN in this case, I'm not sure (possibly
> > > needed to avoid it using ANONYMOUS, which will be offered but
> > > which
> > > then wont actually work unless you then do the $cbs dancing
> > > required
> > > to have claims to do anything). You can use the connection
> > > options for
> > > configuring that too, if needed. You can set the PN_TRACE_FRM=1
> > > env
> > > variable to get protocol trace logging to see what it is actually
> > > going on.
> > >
> > >
> > > On Fri, 5 Aug 2022 at 19:10, Zaq Rizer <idhindsi...@gmail.com>
> > > wrote:
> > > >
> > > > Hey all,
> > > >
> > > > I would like to send directly to Azure Event Hubs using QPID
> > > > Proton from
> > > a
> > > > C++ shared library. The docs on Microsoft's site (
> > > >
> > > https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-c-getstarted-send
> > > )
> > > > are unfortunately out of date and refer to the Qpid AMQP
> > > > Messenger (
> > > > https://qpid.apache.org/proton/messenger.html) which has been
> > > deprecated.
> > > >
> > > > The URL format Microsoft specifies is:
> > > >
> > > > "amqps://{SAS Key Name}:{SAS key}@{namespace
> > > > name}.servicebus.windows.net/{event
> > > <http://servicebus.windows.net/%7Bevent> hub name}";
> > > >
> > > >
> > > > When I copy my SAS token and key (and URL-Encode the key value)
> > > > from
> > > Azure,
> > > > I **AM** able to send a couple dummy messages using Microsoft's
> > > > Python
> > > > example (
> > > >
> > > https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-python-get-started-send
> > > ).
> > > > However, using the *exact same URI with Proton*, I'm getting an
> > > > error
> > > back
> > > > from Azure like:
> > > > "amqp:unauthorized-access: Unauthorized access. 'Send' claim(s)
> > > > are
> > > > required to perform this operation. Resource:
> > > 'sb://{{obfuscated}}.service
> > > > bus.windows.net/{{obfuscated}}
> > > <http://bus.windows.net/%7B%7Bobfuscated%7D%7D>'.
> > > TrackingId:{{obfuscated}},
> > > > SystemTracker:gateway5, Timestamp:2022-
> > > > 08-05T17:54:44"
> > > >
> > > > Keep in mind the "Send claims are required" bit is a red
> > > > herring. This
> > > > event hub already has Send claims. And the Python example works
> > > > just
> > > fine.
> > > >
> > > > I referred to the examples/helloworld, simple_send, direct_send
> > > > but I'm
> > > > getting the same error with all of them.
> > > >
> > > > Thanks very much for any help!
> > > > Zaq
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
