[ejabberd] Psi misbehavior when using latest ejabberd svn version
zbyszek at toliman.pl
Tue Sep 25 10:45:57 MSD 2007
so the discussion went to dead end? maybe we need some XEP-best practices
regarding client behavior - if there isn't already...Peter what you think?
On 9/24/07, Zbyszek Żółkiewski <zbyszek at toliman.pl> wrote:
> 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: 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/
> Zbyszek Żółkiewski
> Zbyszek Żółkiewski
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ejabberd