On invalid login XIFF converts an error 401 auth into a 400 wait

XIFF
1

If you login with invalid details, an XMPP server will correctly return an iq stanza of type ‘error’, embedding an ‘error code=“401” type=“auth”’. XIFF will incorrectly dispatch an event with code 400 of type ‘wait’ - the auth error is lost.

This is because in XMPPConnection.as, line 624, there is a pendingIQs, so the original error is ignored. Instead ‘sendAuthentication_result’ is called, which sees that the error is not of type RESULT, so dispatches an error 400.

This is due to a change by alex in revision 9513.

To fix this either:

  1. line 624 should only check for errors, not for pendingIQs. I suspect there was a good reason for this change in r9513, so the other option is

  2. deal with the error in sendAuthentication_result:

protected function sendAuthentication_result( resultIQ:IQ ):void

{

if( resultIQ.type == IQ.RESULT_TYPE ) {

loggedIn = true;

var event:LoginEvent = new LoginEvent();

dispatchEvent( event );

}

else if( resultIQ.type == IQ.ERROR_TYPE ) {

dispatchError( resultIQ.errorCondition, resultIQ.errorMessage, resultIQ.errorType, resultIQ.errorCode )

}

else {

// We weren’t expecting this

dispatchError( “unexpected-request”, “Unexpected Request”, “wait”, 400 );

}

}

I’m happy to submit a patch.

What do you think? Why is the original error ignored if there are pendingIQs?

Thanks for the help, and keep up the great work with XIFF,

Graham

2

It seems that you’re going thru the same stuff I went lately.

  • Next thing I experienced after the bug you mentioned is that setting MUC chatRoom properties like server and roomname result in exception and can be worked around by setting roomJID instead.

  • sendPrivateMessage in Room does not work. I can share a patch for that

  • And finally I encountered that Room.messageSend won’t send html message - the XHTML extension does not work, library tries to refer to it as to ISerializable, but XHTML extension does not implement that interface. This is next on my TODO list, have you fixed that maybe?

3

I am also seeing this behaviour.

I have tested Graham’s fix and it appears to work just fine.

Is there any chance somebody could check this fix onto trunk?

Rob