[Psi-Devel] Psi misbehaviour?

[Michał Jazłowiecki]

Welcome,

I would like to know whether this Psi behaviour is correct or not:

User tries to use Psi to create a new account on server running ejabberd
(with https://support.process-one.net/browse/EJAB-355 patch applied).
After selecting server and username and password, server responds with
error "Disconnected". The account in Psi is already created, so user
tries to log in and succeeds to do so.

The question is: does Psi "hold" the connection to server while awaiting
for user to provide his credentials? The abovementioned patch for
ejabberd introduces timeouts for client-server connections.

Kind regards,

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

_______________________________________________
Psi-Devel mailing list
Psi-...@lists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com

[zbyszek.z...@gmail.com]

actually "Disconnected" message appears when user selecting "username"
and "passowrd" - this is caused because Psi hold open -
unauthenticated connection to server with in my opinion is wrong.
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.

Zbyszek Żółkiewski
jabster.pl

On Sep 22, 5:25 pm, Michał Jazłowiecki <mich...@poczta.neostrada.pl>
wrote:

> Welcome,
>
> I would like to know whether this Psi behaviour is correct or not:
>
> User tries to use Psi to create a new account on server running ejabberd

> (withhttps://support.process-one.net/browse/EJAB-355patch applied).

> After selecting server and username and password, server responds with
> error "Disconnected". The account in Psi is already created, so user
> tries to log in and succeeds to do so.
>
> The question is: does Psi "hold" the connection to server while awaiting
> for user to provide his credentials? The abovementioned patch for
> ejabberd introduces timeouts for client-server connections.
>
> Kind regards,
>
> --
> Michał Jazłowiecki (michalj)
> Psi Forum & Wiki Moderator
>
> _______________________________________________
> Psi-Devel mailing list

> Psi-De...@lists.affinix.comhttp://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com

[Michał Jazłowiecki]

Welcome,

A comment to my original post from a friend, that somehow didn't make it
to the list (was sent through Google Groups,
http://groups.google.com/group/psi-devel/browse_thread/thread/4d884b0b5ed91ae7):

actually "Disconnected" message appears when user selecting "username"
and "passowrd" - this is caused because Psi hold open -
unauthenticated connection to server with in my opinion is wrong.
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.

Zbyszek Żółkiewski
jabster.pl

[Remko Tronçon]

> 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

[zbyszek.z...@gmail.com]

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.

On Sep 23, 12:34 pm, "Remko Tronçon" <re...@el-tramo.be> 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
> _______________________________________________
> Psi-Devel mailing list

> Psi-De...@lists.affinix.comhttp://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com

[Michał Jazłowiecki]

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

_______________________________________________