[jdev] sasl error on multiple <auth/>?
stpeter at stpeter.im
Mon Aug 29 16:51:42 UTC 2011
On 8/25/11 8:57 AM, Alexander Holler wrote:
> I have a similiar question as the one before. ;)
> What should a server do when he receives an <auth/> after a successfull
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?
More information about the JDev