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

[Peter Saint-Andre]

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
authenticated.

> 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

-- 
Peter Saint-Andre
https://stpeter.im/