[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643475#comment-14643475
]
ASF subversion and git services commented on PROTON-923:
--------------------------------------------------------
Commit 66cef4a31f9411619a2febf8bcb2c96b971c89ea in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=66cef4a ]
PROTON-923: Added some more test and fixed tests to work with default SASL impl
> [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)
