[ejabberd] Fwd: Psi misbehavior when using latest ejabberd svn version

Zbyszek Żółkiewski 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
version
To: Mickaël Rémond <mickael.remond at process-one.net>

here is my answer on Remko post:
http://groups.google.com/group/psi-devel/browse_thread/thread/4d884b0b5ed91ae7
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
occur, disconnect.

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:
>
> Hello,
> 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
> user).
>
> 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.
>
> Cheers,
>
>  --
> Mickaël Rémond
>  http://www.process-one.net/
>
>
>


-- 
pozdrawiam,
Zbyszek Żółkiewski

-- 
pozdrawiam,
Zbyszek Żółkiewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jabber.ru/pipermail/ejabberd/attachments/20070924/ef9d9aea/attachment.htm 


More information about the ejabberd mailing list