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…
That might be the right bug.
Here is my thinking:
- 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.
- 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.
- 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.
- 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.
I’'m curious if you agree with this.
Message was edited by: sphillips