You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2017/08/22 15:15:50 UTC
Setting SASL realm
Reading the SASL docs I think we also need to allow SASL realm to be
set on a per-connection basis, in CONNECTION_BOUND - and expose that in
all bindings. This is because the realm may be set by the server based
on incoming vhost. CONNECTION_BOUND is the only point where we a) have
the incoming vhost and b) authentication is not yet done, so it seems
the right place. I think it's a simple setter on the SASL object, any
other ideas?
On Fri, 2017-08-11 at 18:55 +0000, Gordon Sim wrote:
> > On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote:
> > > This looks fine.
> > >
> > > Can you just confirm that adding this extra field to the frame is still amqp 1.0 protocol compliant (I dont have time to check that today).
>
> From spec:
>
> <type name="sasl-init" class="composite" source="list" provides="sasl-frame">
> <descriptor name="amqp:sasl-init:list" code="0x00000000:0x00000041"/>
> <field name="mechanism" type="symbol" mandatory="true"/>
> <field name="initial-response" type="binary"/>
> <field name="hostname" type="string"/>
> </type>
>
> "This field can be used by AMQP proxies to determine the correct back-end service to connect the
> client to, and to determine the domain to validate the client’s credentials against."
>
>
> - Gordon
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61596/#review182725
> -----------------------------------------------------------
>
>
> On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/61596/
> > -----------------------------------------------------------
> >
> > (Updated Aug. 11, 2017, 5:24 p.m.)
> >
> >
> > Review request for qpid and Andrew Stitcher.
> >
> >
> > Bugs: PROTON-1535
> > https://issues.apache.org/jira/browse/PROTON-1535
> >
> >
> > Repository: qpid-proton-git
> >
> >
> > Description
> > -------
> >
> > allow hostname to be set for sasl-init
> >
> >
> > Diffs
> > -----
> >
> > proton-c/include/proton/sasl-plugin.h cbc6684
> > proton-c/src/sasl/sasl-internal.h fc141b4
> > proton-c/src/sasl/sasl.c a39e602
> >
> >
> > Diff: https://reviews.apache.org/r/61596/diff/1/
> >
> >
> > Testing
> > -------
> >
> >
> > Thanks,
> >
> > Gordon Sim
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Gordon Sim <gs...@redhat.com>.
On 24/08/17 16:38, Alan Conway wrote:
> What I'm getting at is if we have an AMQP server that acts as multiple
> hosts, then you probably want to co-ordinate between whatever you
> regard as the 'host' (SNI, SASL, AMQP, please God let them be the same)
> and SASL realms.
Agreed. SNI, sasl-init and open hostnames should in general all be the
same, and this is the realm for cyrus-sasl. However you can only use the
SNI or sasl-init hostname for the realm, as you need to get it before
authenticating, and the open is only processed after authenticating.
> The same user might exist on different 'hosts' with
> different credentials. The whole point of SASL realms appears to be to
> support that, but you can't do it with proton.
I think the changes required are not large. First the pn_do_init() in
sasl.c needs to actually read the hostname from the wire.
There is already a pnx_sasl_get_remote_fqdn() /
pni_sasl_set_remote_hostname() field on the sasl object that can store
this. At present it seems only to get used on the client side though.
If that gets set, the cyrus-sasl can use it to set the realm on the
server side. I agree with Rob, that if the hostname is not present in
the sasl-init, then it should fallback to using the SNI if that is
available (pn_ssl_get_peer_hostname()).
At present on the client side, proton-c doesn't provide any way to
control what is sent in the sasl-init hostname. However it *does*
already allow you to set the SNI separately if needed, and defaults to
using the hostname which you are using to open a socket. We could use
these to set the hostname on sasl-init at some point as well. If there
is a need to separately control the sasl-init hostname, that would
require a small addition to the public interface. Actually though I
think we can get quite far with what is there already.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2017-08-24 at 16:13 +0200, Rob Godfrey wrote:
> On 24 August 2017 at 15:06, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 24/08/17 13:42, Alan Conway wrote:
> >
> > > On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote:
> > >
> > > > On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
> > > > >
> > > > > > Reading the SASL docs I think we also need to allow SASL realm to be
> > > > > > set on a per-connection basis, in CONNECTION_BOUND - and expose that in
> > > > > > all bindings. This is because the realm may be set by the server based
> > > > > > on incoming vhost. CONNECTION_BOUND is the only point where we a) have
> > > > > > the incoming vhost and b) authentication is not yet done, so it seems
> > > > > > the right place. I think it's a simple setter on the SASL object, any
> > > > > > other ideas?
> > > > > >
> > > >
> > > > I'm not sure if I understand this right. When you say 'vhost', what do
> > > > you mean? The hostname in sasl-init?
> > > >
> > >
> > > The AMQP open hostname (which is normally the hostname passed to sasl-
> > > init I think)
> > >
> >
> > The open is only processed after successful sasl authentication though. I
> > agree that they should most likely be the same value, but I think the
> > sasl-init should be used to determine the vhost/realm as far as auth goes.
>
>
> I think in the case of a TLS connection, where there is an available SNI
> and *no* sasl-init hostname then I would think that you should use the SNI
> name for the host/realm. This is in-line with what the AMQP spec appears
> to be trying to say (in the normal course of events the sasl-init hostname
> should not be different to the SNI hostname or the open hostname).
> Obviously if sasl-init provides a hostname you should use that. In the
> case where your server does not provide vhosts/realms then you should
> probably always ignore what is in sasl-init hostname / SNI.
What I'm getting at is if we have an AMQP server that acts as multiple
hosts, then you probably want to co-ordinate between whatever you
regard as the 'host' (SNI, SASL, AMQP, please God let them be the same)
and SASL realms. The same user might exist on different 'hosts' with
different credentials. The whole point of SASL realms appears to be to
support that, but you can't do it with proton.
>
> -- Rob
>
>
> >
> > If so, the particular sasl mechanism in use has access to that and can
> > > > use it to set the realm (which I am assuming is a term related to the
> > > > sasl impl, e.g. the cyrus-sasl library?).
> > > >
> > >
> > > Right, but a multi-host application might want to make descions based
> > > on the AMQP host *before* the SASL process starts, e.g. to choose the
> > > realm for authentication. SASL mech has access to hostname but has no
> > > notion of mapping that to a realm.
> > >
> > > From sasl.h:
> > >
> > > * A single server may support multiple realms. If the
> > > * server knows the realm at connection creation time (e.g., a server
> > > * with multiple IP addresses tightly binds one address to a specific
> > > * realm) then that realm must be passed in the user_realm field of
> > > * the sasl_server_new call.
> > >
> > > Currently we offer no way to do that.
> > >
> >
> > The cyrus sasl impl could take the sasl-init hostname and use that as the
> > realm. The sasl-plugin interface already exposes that hostname, so all that
> > is required there is actually the change to the cyrus impl (and then of
> > course a way for clients to actually set the hostname).
> >
> >
> > I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
> > > > clients to control the value of hostname that is sent out in sasl-init.
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Rob Godfrey <ro...@gmail.com>.
On 24 August 2017 at 15:06, Gordon Sim <gs...@redhat.com> wrote:
> On 24/08/17 13:42, Alan Conway wrote:
>
>> On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote:
>>
>>> On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
>>>>
>>>>> Reading the SASL docs I think we also need to allow SASL realm to be
>>>>> set on a per-connection basis, in CONNECTION_BOUND - and expose that in
>>>>> all bindings. This is because the realm may be set by the server based
>>>>> on incoming vhost. CONNECTION_BOUND is the only point where we a) have
>>>>> the incoming vhost and b) authentication is not yet done, so it seems
>>>>> the right place. I think it's a simple setter on the SASL object, any
>>>>> other ideas?
>>>>>
>>>>
>>> I'm not sure if I understand this right. When you say 'vhost', what do
>>> you mean? The hostname in sasl-init?
>>>
>>
>> The AMQP open hostname (which is normally the hostname passed to sasl-
>> init I think)
>>
>
> The open is only processed after successful sasl authentication though. I
> agree that they should most likely be the same value, but I think the
> sasl-init should be used to determine the vhost/realm as far as auth goes.
I think in the case of a TLS connection, where there is an available SNI
and *no* sasl-init hostname then I would think that you should use the SNI
name for the host/realm. This is in-line with what the AMQP spec appears
to be trying to say (in the normal course of events the sasl-init hostname
should not be different to the SNI hostname or the open hostname).
Obviously if sasl-init provides a hostname you should use that. In the
case where your server does not provide vhosts/realms then you should
probably always ignore what is in sasl-init hostname / SNI.
-- Rob
>
> If so, the particular sasl mechanism in use has access to that and can
>>> use it to set the realm (which I am assuming is a term related to the
>>> sasl impl, e.g. the cyrus-sasl library?).
>>>
>>
>> Right, but a multi-host application might want to make descions based
>> on the AMQP host *before* the SASL process starts, e.g. to choose the
>> realm for authentication. SASL mech has access to hostname but has no
>> notion of mapping that to a realm.
>>
>> From sasl.h:
>>
>> * A single server may support multiple realms. If the
>> * server knows the realm at connection creation time (e.g., a server
>> * with multiple IP addresses tightly binds one address to a specific
>> * realm) then that realm must be passed in the user_realm field of
>> * the sasl_server_new call.
>>
>> Currently we offer no way to do that.
>>
>
> The cyrus sasl impl could take the sasl-init hostname and use that as the
> realm. The sasl-plugin interface already exposes that hostname, so all that
> is required there is actually the change to the cyrus impl (and then of
> course a way for clients to actually set the hostname).
>
>
> I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
>>> clients to control the value of hostname that is sent out in sasl-init.
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Setting SASL realm
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2017-08-24 at 14:06 +0100, Gordon Sim wrote:
> On 24/08/17 13:42, Alan Conway wrote:
> > On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote:
> > > > On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
> > > > > Reading the SASL docs I think we also need to allow SASL realm to be
> > > > > set on a per-connection basis, in CONNECTION_BOUND - and expose that in
> > > > > all bindings. This is because the realm may be set by the server based
> > > > > on incoming vhost. CONNECTION_BOUND is the only point where we a) have
> > > > > the incoming vhost and b) authentication is not yet done, so it seems
> > > > > the right place. I think it's a simple setter on the SASL object, any
> > > > > other ideas?
> > >
> > > I'm not sure if I understand this right. When you say 'vhost', what do
> > > you mean? The hostname in sasl-init?
> >
> > The AMQP open hostname (which is normally the hostname passed to sasl-
> > init I think)
>
> The open is only processed after successful sasl authentication though.
> I agree that they should most likely be the same value, but I think the
> sasl-init should be used to determine the vhost/realm as far as auth goes.
+1 I didn't know that. Sounds like it might be impossible to do this in
server_init, so we'd have to do something with the cyrus canon_user.
This is more than I bargained for so I'll leave it alone for now.
>
> > > If so, the particular sasl mechanism in use has access to that and can
> > > use it to set the realm (which I am assuming is a term related to the
> > > sasl impl, e.g. the cyrus-sasl library?).
> >
> > Right, but a multi-host application might want to make descions based
> > on the AMQP host *before* the SASL process starts, e.g. to choose the
> > realm for authentication. SASL mech has access to hostname but has no
> > notion of mapping that to a realm.
> >
> > From sasl.h:
> >
> > * A single server may support multiple realms. If the
> > * server knows the realm at connection creation time (e.g., a server
> > * with multiple IP addresses tightly binds one address to a specific
> > * realm) then that realm must be passed in the user_realm field of
> > * the sasl_server_new call.
> >
> > Currently we offer no way to do that.
>
> The cyrus sasl impl could take the sasl-init hostname and use that as
> the realm. The sasl-plugin interface already exposes that hostname, so
> all that is required there is actually the change to the cyrus impl (and
> then of course a way for clients to actually set the hostname).
>
> > > I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
> > > clients to control the value of hostname that is sent out in sasl-init.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Gordon Sim <gs...@redhat.com>.
On 24/08/17 13:42, Alan Conway wrote:
> On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote:
>>> On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
>>>> Reading the SASL docs I think we also need to allow SASL realm to be
>>>> set on a per-connection basis, in CONNECTION_BOUND - and expose that in
>>>> all bindings. This is because the realm may be set by the server based
>>>> on incoming vhost. CONNECTION_BOUND is the only point where we a) have
>>>> the incoming vhost and b) authentication is not yet done, so it seems
>>>> the right place. I think it's a simple setter on the SASL object, any
>>>> other ideas?
>>
>> I'm not sure if I understand this right. When you say 'vhost', what do
>> you mean? The hostname in sasl-init?
>
> The AMQP open hostname (which is normally the hostname passed to sasl-
> init I think)
The open is only processed after successful sasl authentication though.
I agree that they should most likely be the same value, but I think the
sasl-init should be used to determine the vhost/realm as far as auth goes.
>> If so, the particular sasl mechanism in use has access to that and can
>> use it to set the realm (which I am assuming is a term related to the
>> sasl impl, e.g. the cyrus-sasl library?).
>
> Right, but a multi-host application might want to make descions based
> on the AMQP host *before* the SASL process starts, e.g. to choose the
> realm for authentication. SASL mech has access to hostname but has no
> notion of mapping that to a realm.
>
> From sasl.h:
>
> * A single server may support multiple realms. If the
> * server knows the realm at connection creation time (e.g., a server
> * with multiple IP addresses tightly binds one address to a specific
> * realm) then that realm must be passed in the user_realm field of
> * the sasl_server_new call.
>
> Currently we offer no way to do that.
The cyrus sasl impl could take the sasl-init hostname and use that as
the realm. The sasl-plugin interface already exposes that hostname, so
all that is required there is actually the change to the cyrus impl (and
then of course a way for clients to actually set the hostname).
>> I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
>> clients to control the value of hostname that is sent out in sasl-init.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote:
> On 24/08/17 05:53, Andrew Stitcher wrote:
> > I think connection bound is after authentication - unless I'm forgetting
> > things due to vacation all events are after authentication.
>
> Having been poking around in this area recently, I can confirm that
> CONNECTION_BOUND will occur *before* the authentication.
>
> > On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
> > > Reading the SASL docs I think we also need to allow SASL realm to be
> > > set on a per-connection basis, in CONNECTION_BOUND - and expose that in
> > > all bindings. This is because the realm may be set by the server based
> > > on incoming vhost. CONNECTION_BOUND is the only point where we a) have
> > > the incoming vhost and b) authentication is not yet done, so it seems
> > > the right place. I think it's a simple setter on the SASL object, any
> > > other ideas?
>
> I'm not sure if I understand this right. When you say 'vhost', what do
> you mean? The hostname in sasl-init?
The AMQP open hostname (which is normally the hostname passed to sasl-
init I think)
> If so, the particular sasl mechanism in use has access to that and can
> use it to set the realm (which I am assuming is a term related to the
> sasl impl, e.g. the cyrus-sasl library?).
Right, but a multi-host application might want to make descions based
on the AMQP host *before* the SASL process starts, e.g. to choose the
realm for authentication. SASL mech has access to hostname but has no
notion of mapping that to a realm.
From sasl.h:
* A single server may support multiple realms. If the
* server knows the realm at connection creation time (e.g., a server
* with multiple IP addresses tightly binds one address to a specific
* realm) then that realm must be passed in the user_realm field of
* the sasl_server_new call.
Currently we offer no way to do that.
> I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
> clients to control the value of hostname that is sent out in sasl-init.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Gordon Sim <gs...@redhat.com>.
On 24/08/17 05:53, Andrew Stitcher wrote:
> I think connection bound is after authentication - unless I'm forgetting
> things due to vacation all events are after authentication.
Having been poking around in this area recently, I can confirm that
CONNECTION_BOUND will occur *before* the authentication.
> On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
>> Reading the SASL docs I think we also need to allow SASL realm to be
>> set on a per-connection basis, in CONNECTION_BOUND - and expose that in
>> all bindings. This is because the realm may be set by the server based
>> on incoming vhost. CONNECTION_BOUND is the only point where we a) have
>> the incoming vhost and b) authentication is not yet done, so it seems
>> the right place. I think it's a simple setter on the SASL object, any
>> other ideas?
I'm not sure if I understand this right. When you say 'vhost', what do
you mean? The hostname in sasl-init?
If so, the particular sasl mechanism in use has access to that and can
use it to set the realm (which I am assuming is a term related to the
sasl impl, e.g. the cyrus-sasl library?).
I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing
clients to control the value of hostname that is sent out in sasl-init.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2017-08-24 at 00:53 -0400, Andrew Stitcher wrote:
> I think connection bound is after authentication - unless I'm forgetting
> things due to vacation all events are after authentication.
Not according to my tests - the connection parameters are copied to the
sasl object in bind() but the sasl handshake starts after the bound
event. The ruby container tests seem to work on that basis. To be
double-checked
>
> A
>
> On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
> > Reading the SASL docs I think we also need to allow SASL realm to be
> > set on a per-connection basis, in CONNECTION_BOUND - and expose that in
> > all bindings. This is because the realm may be set by the server based
> > on incoming vhost. CONNECTION_BOUND is the only point where we a) have
> > the incoming vhost and b) authentication is not yet done, so it seems
> > the right place. I think it's a simple setter on the SASL object, any
> > other ideas?
> >
> > On Fri, 2017-08-11 at 18:55 +0000, Gordon Sim wrote:
> > > > On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote:
> > > > > This looks fine.
> > > > >
> > > > > Can you just confirm that adding this extra field to the frame is still amqp 1.0 protocol compliant (I dont have time to check that today).
> > >
> > > From spec:
> > >
> > > <type name="sasl-init" class="composite" source="list" provides="sasl-frame">
> > > <descriptor name="amqp:sasl-init:list" code="0x00000000:0x00000041"/>
> > > <field name="mechanism" type="symbol" mandatory="true"/>
> > > <field name="initial-response" type="binary"/>
> > > <field name="hostname" type="string"/>
> > > </type>
> > >
> > > "This field can be used by AMQP proxies to determine the correct back-end service to connect the
> > > client to, and to determine the domain to validate the client’s credentials against."
> > >
> > >
> > > - Gordon
> > >
> > >
> > > -----------------------------------------------------------
> > > This is an automatically generated e-mail. To reply, visit:
> > > https://reviews.apache.org/r/61596/#review182725
> > > -----------------------------------------------------------
> > >
> > >
> > > On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> > > >
> > > > -----------------------------------------------------------
> > > > This is an automatically generated e-mail. To reply, visit:
> > > > https://reviews.apache.org/r/61596/
> > > > -----------------------------------------------------------
> > > >
> > > > (Updated Aug. 11, 2017, 5:24 p.m.)
> > > >
> > > >
> > > > Review request for qpid and Andrew Stitcher.
> > > >
> > > >
> > > > Bugs: PROTON-1535
> > > > https://issues.apache.org/jira/browse/PROTON-1535
> > > >
> > > >
> > > > Repository: qpid-proton-git
> > > >
> > > >
> > > > Description
> > > > -------
> > > >
> > > > allow hostname to be set for sasl-init
> > > >
> > > >
> > > > Diffs
> > > > -----
> > > >
> > > > proton-c/include/proton/sasl-plugin.h cbc6684
> > > > proton-c/src/sasl/sasl-internal.h fc141b4
> > > > proton-c/src/sasl/sasl.c a39e602
> > > >
> > > >
> > > > Diff: https://reviews.apache.org/r/61596/diff/1/
> > > >
> > > >
> > > > Testing
> > > > -------
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Gordon Sim
> > > >
> > > >
> > >
> > >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Setting SASL realm
Posted by Andrew Stitcher <as...@fastmail.fm>.
I think connection bound is after authentication - unless I'm forgetting
things due to vacation all events are after authentication.
A
On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote:
> Reading the SASL docs I think we also need to allow SASL realm to be
> set on a per-connection basis, in CONNECTION_BOUND - and expose that in
> all bindings. This is because the realm may be set by the server based
> on incoming vhost. CONNECTION_BOUND is the only point where we a) have
> the incoming vhost and b) authentication is not yet done, so it seems
> the right place. I think it's a simple setter on the SASL object, any
> other ideas?
>
> On Fri, 2017-08-11 at 18:55 +0000, Gordon Sim wrote:
> > > On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote:
> > > > This looks fine.
> > > >
> > > > Can you just confirm that adding this extra field to the frame is still amqp 1.0 protocol compliant (I dont have time to check that today).
> >
> > From spec:
> >
> > <type name="sasl-init" class="composite" source="list" provides="sasl-frame">
> > <descriptor name="amqp:sasl-init:list" code="0x00000000:0x00000041"/>
> > <field name="mechanism" type="symbol" mandatory="true"/>
> > <field name="initial-response" type="binary"/>
> > <field name="hostname" type="string"/>
> > </type>
> >
> > "This field can be used by AMQP proxies to determine the correct back-end service to connect the
> > client to, and to determine the domain to validate the client’s credentials against."
> >
> >
> > - Gordon
> >
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/61596/#review182725
> > -----------------------------------------------------------
> >
> >
> > On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> > >
> > > -----------------------------------------------------------
> > > This is an automatically generated e-mail. To reply, visit:
> > > https://reviews.apache.org/r/61596/
> > > -----------------------------------------------------------
> > >
> > > (Updated Aug. 11, 2017, 5:24 p.m.)
> > >
> > >
> > > Review request for qpid and Andrew Stitcher.
> > >
> > >
> > > Bugs: PROTON-1535
> > > https://issues.apache.org/jira/browse/PROTON-1535
> > >
> > >
> > > Repository: qpid-proton-git
> > >
> > >
> > > Description
> > > -------
> > >
> > > allow hostname to be set for sasl-init
> > >
> > >
> > > Diffs
> > > -----
> > >
> > > proton-c/include/proton/sasl-plugin.h cbc6684
> > > proton-c/src/sasl/sasl-internal.h fc141b4
> > > proton-c/src/sasl/sasl.c a39e602
> > >
> > >
> > > Diff: https://reviews.apache.org/r/61596/diff/1/
> > >
> > >
> > > Testing
> > > -------
> > >
> > >
> > > Thanks,
> > >
> > > Gordon Sim
> > >
> > >
> >
> >
>
--
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org