[ejabberd] Fwd: Psi misbehavior when using latest ejabberd svn version
zbyszek at toliman.pl
Mon Sep 24 14:11:17 MSD 2007
sorry, mail not went to all..resending..
---------- Forwarded message ----------
From: Zbyszek Żółkiewski <zbyszek at toliman.pl>
Date: Sep 24, 2007 12:09 PM
Subject: Re: [ejabberd] Psi misbehavior when using latest ejabberd svn
To: Mickaël Rémond <mickael.remond at process-one.net>
here is my answer on Remko post:
the problem seams to be bigger - i thin Gajim(svn) also uses the same
technique as Psi - not tested but some user reports say that there are
problems with registering account.
For now i have changed default timeout in ejabberd_c2s.erl from 5s to 60s
with should temporary resolve registration issues.
As for the problem, as i write on Psi-devel list it should by held by the
client - there is no reason (in my opinion) to hold open connection - even
when policy will change - user will not be registered, so reassuming, 2
stages for client (can be shorten to only one stage)
1) select server, and check features (if in-band registration is enabled, if
not advise user), disconnect
2) user selects username and password - this can be long as users may
selecting user and password longer time - also some clients may provide some
kind password-measurement tools, even so - we should not hurry user in any
situation, after that client reconnect to server, check features again and
if policy have hanged, advise user, register account if no other errors
i think this is most simple solution for that problem.
On 9/24/07, Mickaël Rémond <mickael.remond at process-one.net > wrote:
> I agree with you. Psi should not open a connection that is kept into
> unauthenticated state too long.
> Your solution posted on Psi mailing list seems correct.
> However, Remko points is correct too. In very rare case, you could try to
> push a form that has changed or rejecting registration because it is not
> more authorized.
> Avoidting timeouts does not make the situation better however. In
> ejabberd, you can change the policy without restarting the server). It could
> be changed in the middle of a user registration (This is correct for a user
> to change his policy even if the user has retrieved the form to create a
> In my opinion this should be handled by the client displaying the error to
> the user. There are in any case lots of possible error case (user exists for
> example, missing mandatory field), it could be unauthorized creation or
> missing field.
> Please, let me know if you disagree.
> Mickaël Rémond
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ejabberd