Yes, Andrew, thank you for pointing that out for the thread. I stumbled
upon (I think it might have been you actually?) a comment to this effect in
a Jira ticket or a Github issue and that led me to attempting service_bus,
and found that generally "just worked". Our use case is Azure event hubs,
but it's nearly identical (as far as Azure is concerned).
I greatly appreciate you taking the time to chime in!
On Tue, Aug 9, 2022 at 8:23 AM Andrew Stitcher <astitc...@redhat.com> wrote:
> 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>
> > > > <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>
> > > > <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
>
>
