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/ _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
