[Psi-Devel] Psi misbehaviour?

Michał Jazłowiecki michalj at poczta.neostrada.pl
Sun Sep 23 05:05:43 PDT 2007


Welcome,


Once again Google Groups did not work correctly :/ Here's the answer 
from my friend:


i hope this time it reach the group. to be clear about timeouts here
is quote from EJAB-355:

"The negociation of the client connexion should implement timeouts.
This way a client cannot stay indefinitely in an intermediate state
between the TCP connexion and the session opening.
This is to prevent possible denial of service by opening many TCP/IP
connections without actually proceeding to authentication."

and this is what Psi does. We don't have lot mechanisms to prevent
abuses in server implementation and timeout (default 5s) in ejabberd
is one of good solutions as
staying too long in intermediate state is in general bad idea.
And about that rare cases when in-band registration is disabled - i
guess this is very-very rare, probably situations that never happen,
but even so Psi could check again for inband and if feature is not
present during registration - advise user that server features have
been changed.


Remko Tronçon wrote:
>> I think proper behavior should be like: after checking server features
>> connection to server should be closed and reopened again for in-band
>> registration _after_ user decided their username and password.
> 
> Hmm, I'm not 100% sure this is what you want. This approach does not
> guarantee atomicity, so the server might have changed its in-band
> registration requirements by the time you re-connect, causing a rare
> but weird chain of events (and the corresponding code for it). I'm
> inclined to say that the connection should not timeout, but I'ld
> gladly be convinced otherwise.
> 
> cheers,
> Remko


-- 
Michał Jazłowiecki (michalj)
Psi Forum & Wiki Moderator



More information about the Psi-Devel mailing list