Potential bug

Openfire Plugins Kraken - IM Gateway
1

I am trying to track down the reason for this problem I am experiencing with beta 8 and spark:

  1. Use spark to log into a gateway (yahoo, aim, etc) using the “Enter Login Information” menu item

  2. Notice that it logs in fine and the contacts are imported

  3. Use the “Delete Login Information” function to remove the login

  4. Notice that the gateway becomes deregistered and the contacts get removed properly

  5. Use spark again to log into the gateway using the “Enter Login Information” menu item

  6. Notice that the gateway doesnt get logged into and the contacts don’'t appear

If you log out of XMPP and then reconnect the gateway will come up fine though. Has anyone else seen this issue? The stanzas being sent to the server are identical on steps #1 and #6.

2

What version of the plugin are you using?

Typically that is caused of the transport does not correctly label you as logged out. Are you certain it’'s happening with all of the transports? Or just a couple?

3

I am using version 1.0 Beta 8. It does seem to happen with all the transports. The gatewayRegistration table in the database gets updated properly with the new login information, but the LastLogin field is NULL which seems to indicate that the gateway doesnt attempt to login the user to the gateway.

Like I said though, if I log out and log back in to my XMPP account the gateway works fine. I think the only problem is that the plugin doesnt attempt to login.

I tested this with Spark and Exodus and also my custom client.

A futher question I had along the same lines: if I send registration info multiple times to the gateway will the username/password be updated properly? For example if I send this:

will the transport use password2 and attempt to login again, or do I need to unregister from the gateway first?

4

GATE-191 =)

And for the latter, yes, if you reregister it “overwrites” your current registration. Though… I don’'t think it triggers a logout and login. (all it might do right now is probe for a login) GATE-192

Message was edited by: jadestorm

5

Question regarding this (I am using the 1.0 release now):

I am noticing that if I am logged in with a Yahoo account of “foo” and then attempt to connect a Yahoo account of “foo1” I get this stanza exchange:

SEND:

and I do not get the roster list for “foo1”. However if I disconnect from the Jabber server and reconnect it will login to Yahoo as “foo1”.

This is the way I thought it would work:

  1. Log in as Yahoo user “foo”

  2. User “foo” Yahoo contact list gets imported

  3. Login as Yahoo user “foo1”

  4. The contacts for Yahoo user “foo” gets removed from the roster along with the “foo” registration

  5. User “foo1” gets logged in and the account for “foo1” get imported.

The reason that may be a problem is sometimes people type in the wrong password for their Yahoo accounts and their roster doesn’‘t come in because the transport can’'t log into their Yahoo account. So they try to reregister with the correct password without disconnecting from the Jabber server, but the transports dont seem to recognize the new password and pull in the roster.

I think sending a new ‘‘jabber:iq:register’’ stanza to the transport should deregister any existing registrations on that transport and reregister the user with the new account information. Thanks!

Message was edited by: sphillips

6

It actually does clear out the old registration and save the new one. Most likely it’‘s getting stuck in a state the first time where it thinks you are already logged in and doesn’'t try again. See GATE-160

Message was edited by: jadestorm

(oops make that GATE-160, not GATE-180)

7

That might be the right bug.

Here is my thinking:

  1. If someone attempts to log into a transport using iq:register using incorrect username/password then nothing should happen (except return an error) and the login credentials should not be put into the database. I think currently the login credentials get put into the database which makes the transport think the user is “logged in”.

  2. If someone attempts to log into a transport using iq:register and the username/password that they provide are identical to the username/password they provided in previous attempts then nothing should happen.

  3. If someone attempts to log into a transport using iq:register and the username/password that they provide are different from the username/password they provided in a previous attempt then they should be deregistered from the previous registration (contacts removed, etc) and a new registration should be created (contacts imported, etc).

  4. If someone attempts to log into a transport using iq:register and they have never attempted to register previously a new registration should be created (contacts imported, etc).

I’'m curious if you agree with this.

Thanks

Message was edited by: sphillips

8

Yes, we are talking about the same thing. Except that part of what’'s happening is a symptom of another bug. But let me discuss below…

sphillips wrote:

That might be the right bug.

Here is my thinking:

  1. If someone attempts to log into a transport using iq:register using incorrect username/password then nothing should happen (except return an error) and the login credentials should not be put into the database. I think currently the login credentials get put into the database which makes the transport think the user is “logged in”.

There is an issue for this functionality in the issue tracker. I do not currently check the username and password at registration. Instead, once the user attempts to log in (which should happening automagically after the registration occurs) the transport will see an incorrect password and spit that back to the user.

  1. If someone attempts to log into a transport using iq:register and the username/password that they provide are identical to the username/password they provided in previous attempts then nothing should happen.

I actually update their registration anyway for posterity sake, but hey.

  1. If someone attempts to log into a transport using iq:register and the username/password that they provide are different from the username/password they provided in a previous attempt then they should be deregistered from the previous registration (contacts removed, etc) and a new registration should be created (contacts imported, etc).

This is effectively what is supposed to occur. Part of the problem is that with the MSN transport at least, possibly others, is that when you attempt to log in and fail, I’‘m not properly indicating that you didn’‘t log in internally. So then you register with your correct username/password and your registration is updated with the new information. Ideally this should trigger a “logout” (which won’‘t really do anything because you weren’‘t logged in to begin with) and then a login. However, the logout isn’‘t triggering because there’‘s nothing to log out of, but the login isn’‘t triggering because the internal state is that the person is still “logging in” so it thinks there’‘s no reason to try logging in a second time right now. The roster “fixing up” occurs after you’'ve logged in successfully when the transports runs through and updates things.

  1. If someone attempts to log into a transport using iq:register and they have never attempted to register previously a new registration should be created (contacts imported, etc).

That’'s what occurs now.

Daniel

I’'m curious if you agree with this.

Thanks

Message was edited by: sphillips