You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Zaq Rizer <id...@gmail.com> on 2022/08/05 18:09:52 UTC
Addressing for Azure Event Hubs
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 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}}'. 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
Re: Addressing for Azure Event Hubs
Posted by Zaq Rizer <id...@gmail.com>.
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 <as...@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 <id...@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
> > > <ro...@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 <id...@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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Addressing for Azure Event Hubs
Posted by Andrew Stitcher <as...@redhat.com>.
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 <id...@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
> > <ro...@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 <id...@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Addressing for Azure Event Hubs
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <id...@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 <ro...@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 <id...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Addressing for Azure Event Hubs
Posted by Zaq Rizer <id...@gmail.com>.
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 <ro...@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 <id...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Addressing for Azure Event Hubs
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <id...@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 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}}'. 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org