« Hide

Steps to reproduce:
1. Run the following test from the qa-regress webapp: http://localhost:8400/qa-regress/testsuites/mxunit/tests/messagingService/security/streaming-amf/JMSAuthSendSubscribeConstraintTest.mxml
2.
3.
 
 Actual Results: A couple of the test methods fail. If you look at the testValidCredentials test method, you'll see that the failure message is "Credentials were valid, shouldn't have received fault: Client.Error.MessageSend".
 
 
 Expected Results: Should get an authentication error. If I change the test to check for the faultcode "Client.Error.MessageSend" in addition to the other authentication fault codes, the tests all pass. In the streaming case it seems like we aren't getting the authentication failure back to the user but are returning this message instead. I think developers who are looking for/expecting an authorization fault code will find this confusing.
 
 
 Workaround (if any):
 
 
 

Show »

Steps to reproduce: 1. Run the following test from the qa-regress webapp: http://localhost:8400/qa-regress/testsuites/mxunit/tests/messagingService/security/streaming-amf/JMSAuthSendSubscribeConstraintTest.mxml 2. 3.    Actual Results: A couple of the test methods fail. If you look at the testValidCredentials test method, you'll see that the failure message is "Credentials were valid, shouldn't have received fault: Client.Error.MessageSend".      Expected Results: Should get an authentication error. If I change the test to check for the faultcode "Client.Error.MessageSend" in addition to the other authentication fault codes, the tests all pass. In the streaming case it seems like we aren't getting the authentication failure back to the user but are returning this message instead. I think developers who are looking for/expecting an authorization fault code will find this confusing.      Workaround (if any):