[jira] [Commented] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644471#comment-14644471
]
Andrew Stitcher commented on PROTON-923:
This is the issue for raising the correct type of transport error on
authentication failure.
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643281#comment-14643281
]
ASF subversion and git services commented on PROTON-923:
Commit 236ee166e6a6770f48099fd4d5f38a64331cee40 in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=236ee16 ]
PROTON-923: New tests to test the events emitted associated with SASL
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643485#comment-14643485
]
Andrew Stitcher commented on PROTON-923:
I can't reproduce this bug with the current master branch of Proton-C.
I've added some tests to check the events being produced and TRANSPORT_ERROR
does seem to be produced.
[It is true that the condition is still amqp:connection:framing_error which is
not really the correct error (amqp:unauthorized-access seems to be the correct
error condition), but the error event is being produced]
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
