[jdev] sasl error on multiple <auth/>?

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 29 16:51:42 UTC 2011

On 8/25/11 8:57 AM, Alexander Holler wrote:
> Hello,
> I have a similiar question as the one before. ;)
> What should a server do when he receives an <auth/> after a successfull
> negotiation?

So SASL negotiation is complete but the client or peer server sends new
SASL <auth/> elements? Why would it do that (other than being buggy)?
There is no re-authentication option in XMPP.

> RFC 6120 6.4.2 only defines what happens when the authentication isn't
> completed but not what happens when the authentication was completed.
> Maybe a <failure/> with <malformed-request/>. 

I'd say just ignore the new <auth/> element, since the entity is already

> Or should the server
> proceed and throw away the authentication done before?

No. There's no re-authentication option.

> It's easy to fool clients into doing that, just announce <mechanisms/>
> in <features/> when the stream got restarted after successfull
> authentication. That itself isn't the correct thing to do, but happens. ;)

Why design around buggy servers?


Peter Saint-Andre

More information about the JDev mailing list