I have the next problem . I register some external account from external protocol like msn or yahoo, and the server
don''t alert me if i make a mistake with my password or username ... Somebody know something about this?
It will notify the person after they actually log in. There are logistics issues associated with checking the username and password at registration time unfortunately. (you can''t do it unless you actually log in, which can cause some problems where, for exmaple, someone might see you pop on and im you, or whatever, lots of "bad things" can occur if you do that) But yeah, once they try to log in they should get a message saying "your username or password is incorrect, please re-register with your correct username and password" or something like that.
ok. I really want to know what bad things do you refer? And is it problem of the server openfire or is it because the external protocols don''t permit this alert?
I want to understand why is happening this behavior? Can you help me? please. Thanks for your amability.
Moreso than anything, it''s a matter of us being a "level of abstraction" above a standard, for example, MSN client. We''ll use MSN as an example. When you first run MSN messenger and you tell it your username and password, it doesn''t tell you that that password is invalid immediately. However, once you go to log in (which, granted, is often automatic after you enter your username and password) it will try your username and password with MSN and if it''s wrong, it will pop up a "that username or password is invalid" message.
Now what is missing here is that there''s no way to contact MSN and simply get a "is this username and password valid?" response. You have to actually log in.
Now take the transport. You enter your username and password via XMPP mechanisms from your XMPP client. (OR you do it via the admin interface) Now the registration process itself is -not- supposed to trigger you logging into the remote service. Only an available presence to the transport is supposed to trigger a true MSN login. So anyway, during registration your username and password is recorded and the only way I would be able to test to see if it''s valid is to actually try to log you into MSN.
1. This is not "supposed to happen". The registration process is not supposed to trigger an actual login to the service. Now lets ignore that issue for a moment...
2. To successfully test, I''ll have to log you in, see if it worked, and then log you out. Now what if someone sees you log on and tries to contact you. Alternatively, what if you had some pending offline messages waiting for you and they get sent to your login ... but we don''t care about those messages, all we''re doing is testing your username and password. The offline messages would get chucked to the curb.
If there were only a mechanism to simply pass a username and password to MSN and have it return "yeah that''s valid" then this could be done.
So... that said. The process surrounding registration usually goes something like this:
1. User wants to register with MSN transport
2. MSN transport says "ok, I need your username and password"
3. User sends username and password
4. MSN transport stores that information
5. MSN transport says "hey, are you logged in right now?"
6. If you are logged in, it automatically logs the user into MSN
7. During the login process, if the password is invalid, you -should- get a message from the MSN transport saying that your username or password is not valid
Note that if you registered via the administrative interface, there''s a good chance that the user is not logged in right now, so they''ll see the username and password is not valid message the next time they try to log in.
There''s a number of other things that can occur if I were to try to log someone in, immediately log them out, and log them back in soon after. Some services might consider this an attempt to DOS the service and deny your logins. (ICQ and AIM are especially bad about booting you the moment you might be causing troble)
Ok, thanks for your help. You´re so attentive.
Retrieving data ...