AIM Login Issues

Hi,

I’'m using the gateway plug in 1.1.0 beta 1, openfire 3.3 and smack 3.0.1 to talk from my Java code to the openfire server.

I’'m accepting people signing into their MSN / ICQ / AIM accounts via my mini system. When they first enter their details I call the method below - this method attempts to register with the transport and then assuming that works without a hitch it will set the presence on the transport to force the login. (it is based heavily on the PoC code in the ignite code repository).

public boolean registerWithTransport(Transport transport, String username, String password) {

try {

// These filters and collectors are needed when processing

// packets to and from the transports

PacketCollector regAck = connection.createPacketCollector(new PacketTypeFilter(Registration.class));

AndFilter msgFromTransport = new AndFilter();

msgFromTransport.addFilter(new PacketTypeFilter(Message.class));

msgFromTransport.addFilter(new FromMatchesFilter(transport.getJid()));

AndFilter subRequestFromTransport = new AndFilter();

subRequestFromTransport.addFilter(new PacketTypeFilter(Presence.class));

subRequestFromTransport.addFilter(new FromMatchesFilter(transport.getJid()));

PacketCollector msgAck = connection.createPacketCollector(msgFromTransport);

PacketCollector subReq = connection.createPacketCollector(subRequestFromTransport);

// With these blocking collectors in place we’'ll now process the registration

// This block starts the conversation with the transport

Registration conv1 = new Registration();

conv1.setType(IQ.Type.GET);

conv1.setTo(transport.getJid());

connection.sendPacket(conv1);

// When the transport has acknowledge this or a timeout has occured we continue

Registration regRep = (Registration) regAck.nextResult(5000);

if ( regRep == null ) {

// if the response was null it means an ack didn’'t come in

// within the 5second max.

return false;

}

// As we got a response we’'ll now register our details with the server

Registration regReq = new Registration();

regReq.setType(IQ.Type.SET);

regReq.setTo(transport.getJid());

DataForm registerDetails = new DataForm(“submit”);

FormField transUser = new FormField(“username”);

FormField transPass = new FormField(“password”);

transUser.addValue(username);

transPass.addValue(password);

registerDetails.addField(transUser);

registerDetails.addField(transPass);

regReq.addExtension(registerDetails);

connection.sendPacket(regReq);

Message response = (Message) msgAck.nextResult(5000);

if ( response == null || ( response != null && response.getType() != Message.Type.error ) ) {

Presence goOnline = new Presence(Presence.Type.available);

goOnline.setTo(transport.getJid());

connection.sendPacket(goOnline);

clientRoster.addTransport(transport.getJid());

return true;

}

} catch (XMPPException e) {

//Add transport failed

}

return false;

}

Now the issue - in the case of ICQ and MSN this method provides a 98% success rate. In the case of AIM it only succeeds 39% of the time.

I need to qualify that statement; by succeed I mean it returns true, and then the person can see their contacts from that transport.

What is likely to be the issue here? I think a possiblity is that the msgAck.nextResult(5000) is not returning within the 5seconds and is resulting in me assuming the registration was successful, when in reality AOL hasn’'t responded just yet and actually the provided credentials are incorrect. Assuming this is the case what is a realistic timespan to put in this timeout?

Before I put the timeout in I was blocking until a response came through - however I realized that a response didn’'t come through in a number of cases (this was with a pre 1.0 gateway plug in). This seemed to fly against what the gateway XEP said would happen. Can someone confirm whether upon successful registration the gateway will return a success message?

Which log files will be reporting the bad credentials? What am I looking for in those log files. Will there be anything in the log file if I’'m timing out and continuing my code flow after the 5seconds?

Help/Hints much appreciated

RE: the method in the message above - it’'s clearly not formatted nicely - I tried my hardest to get it to do so (tried the plain text editor and the rich text editor and I could get it to work. If anyone has a suggestion about how I can paste that and it work please let me know

I’'ve been doing some more investigation here - this is what I have found so far.

The gateway plugin, for MSN and AIM at the very least, doesn’'t respond with a “success” message when it successfully registers with a messaging service. This is directly against XEP-100 (http://www.xmpp.org/extensions/xep-0100.html#usecases-jabber-register-pri step 6). However it does respond with an error if the credentials are incorrect.

In my case it would seem that sometimes the gateway (AIM) is taking a while to respond and my timeout occurs (5seconds) and I assume it is a correct signup. I make this assumption because of the statement above - if the gateway plugin sent the success message to the client it wouldn’'t be so bad, I could set a high timeout value to account for slowness and in the case of a timeout assume there is an issue with the provider.

Jadestorm - how to proceed in making sure the gateway replies with a success message to registrations if they are correct?

Mike

Hey - so further thoughts on this.

org/jivesoftware/openfire/gateway/BaseTransport.java

if (!foundReg) {

registrationManager.createRegistration(jid, this.transportType, username, password, nickname);

triggerRestart = true;

}

createRegistration is actually returning a Registration object - can you not use this object to verify whether the registration happened correctly and if it did then return a success Message? I see that you return fails if a part of the process returns an exception (though I can only find that for the web stuff - not where the beginning stub for this is for a “normal” client).

Thoughts?

Mike

Ok bear with me, I’‘m stranded in freakin’’ Dallas, Texas, and apparently am stuck here for two days. I’'m not in a great state of mind.

That said, first off, the error messages through invalid credentials is not coming from the registration process… unless you are referring to illegal usernames or something like that … but at present I don’'t verify that your username and password is truly valid on the legacy network because there are some logistics issues there that I need to work out in my head.

Anyway, so it sounds like I’‘m not sending success back. Dooh. The createRegistration step you see is just creating it in the database, and doesn’'t imply that it works on the legacy network. That said, it sounds like I ought to be sending the success there. See GATE-267

Hrm actually I am sending success back. addNewRegistration is used by other things, so you have to find where it’'s being called. That said, there was a problem with it in that I was returning success whether there was an error or not. I adjusted that in my local copy to be committed to svn at some point.

Hey - sorry to hear about the strandedness. I spent some 6 hours in SFO cos OHare was screwed a few months back - airports are not particularly nice places!

Anyways,

So I just want to make sure we’'re on the same page here.

My code snippet from the original post shows me waiting for 5 seconds for feedback from the gateway that the registration with the legacy network has worked. After that 5 seconds expires I have to assume it has worked because the gateway plug-in is never returning a success message to this registration. So far on my dev product I’‘ve left this thing running for up to a minute waiting for a success reply and it doesn’'t come through.

You do however reply with an error message if the details are incorrect. But in my case it seems that AIM can take a while to confirm that a particular credential is incorrect. By increasing the timeout time waiting for the confirmation/error I unfairly penalize users which have entered correct information.

XEP-100 says that the gateway SHOULD reply with a confirmation message if the registration is correct

Cool? I think that qualifies for a gate

Right, what I was trying to point out is that it is supposed to be returning something judging by my read of the code. Unfortunately I can’‘t read the code as pasted here enough to tell what’‘s going on. (maybe you could email me a copy? jadestorm@nc.rr.com) Look in handleIQRegister, and look for where addNewRegistration is called. Right before that I add to the reply queue a result IQ that creates the “success” packet. The only difference between what XEP-0100 specifies and what I am returning there is that I added a . As far as I can tell that should be perfectly valid though. I can see the success come back to Psi (and in fact Psi won’'t tell you it worked until it gets that successful response).

Okay - thanks for that. i’'ll take a look again later tonight.

Smack is not the most friendly lib when trying to build up listeners.

mike

It’‘s not especially friendly with me for a couple of things. ;D I’‘m pleased to say that another dev patched up Smack to make it asynchronous btw. I’'m going to hand over the patches to the Smack devs so they can maybe incorporate the asynch concept into the main line. =)

Hey

So having looked about your code some, and edited mine I managed to get this thing working so that when I get a response I deal with it quickly. It does however mean I’'m coupled incredibly scarily close to your code - if you were to add a packet in there somewhere or change it like that it would break my code. I cannot really see a solution to this at the moment.

My only real thought/suggestion is that in the try block of handleIQRegister you return a message with a success code in it. Right now you return a Registration packet in both an error and a success. The only difference with the error is that there is a message packet. At least if in both cases a message packet came back then the developer only has to inspect the result of that packet (in the case of smack making it much easier).

try {

this.addNewRegistration(from, username, password, nickname, rosterlessMode);

Message sm;

sm.setType(Message.type.normal);

sm.setTo(packet.sm.setFrom(packet.getTo());

reply.add(sm);

}

(above my be formatted ugly - I’'ve added so many line feeds to try to get this editor to post it nicely but it seems to not work)

Thoughts?

Mike

Right - I added some more debug here. XEP-100 says you should return the following when some details are not correct

I guess the real issue from a developers point of view is that no standard is currently returned in your solution. XEP-100 suggests the standard standard, but this developer would prefer the non-standard method you have here - I like message stanza’‘s over IQ stanza’'s mainly because they have types in the smack library.

What are your thoughts?

Uhm. I don’‘t know why you aren’‘t seeing it, but I am returning the standard response -in addition to- the message you see. =) I dont’’ know why it’'s not getting through to you though. (I see it clearly in the XML console of Psi)

Unless of course this is the response from AIM saying that your username and password is not correct. Note that at present I can -not- tell you whether that was successful or not during the registration process. I simply don’‘t have the knowledge as to whether your username and password is going to work in the legacy service during registration. Note that as far as I’‘ve seen no transport supports that yet. It involves a mess of things. Lets take a scenario where I actually test to log you into AIM after you’‘ve registered just to see if your username and password works. Well all I’‘m doing is a quick connect and disconnect, I don’‘t really -want- to log you all the way in just yet. So what happens if someone IMs you during that time? I’‘m basically going to throw away your incoming message because I don’‘t have a full session set up. There’‘s no way that I’‘m aware of to “just check” your username and password with most of these services. There’‘s an issue filed in the tracker relating to trying to figure out a good way to work this out, though I’‘m not sure such a thing is going to exist. We’'ll see.

The actual handling of the registration process does indeed spit back error iq error messages like it’‘s supposed to if there’'s an actual problem with the -registration- piece. Registration != knowing that your username and password will work.

Message was edited by: jadestorm

GAH, I got distracted whilst writing that post last night. Sorry.

I AM getting a message stanza which says it failed if I enter incorrect details.

I NOT getting a message stanza saying it succeeded. At the moment it seems the code is only confirming it worked by the fact that there isn’'t an error message stanza.

I actually took a tcpdump of the jabber stuff during a successful registration and an unsuccessful one. In the case of a successful one I get only a Registration IQ packet back. In the unsuccessful case I get a Registration IQ packet back and a message packet back of the type error.

My suggestion is to keep the two situations standard - so a developer using this plugin knows that they get a message stanza back and they only have to inspect it’'s type, error or normal, to signify whether or not the registration worked or not.

Unless perhaps I’‘m being stupid and the method which calls handleIQRegister is adding more stanza’'s to the List being returned?

Mike

Odd, I can duplicate the issue now. (I didn’‘t see the stanza at first, since it was amongst presence packets, I still can’‘t duplicate it not working) Anyway, I’'m not going to “only” send a message stanza because that violates the XEP. (ie, i need to send the iq response) By the same token, I send the error message along because it provides an easy to read/understand explanation of what happened. In general you should be able to follow the conversation as described in XEP-0100 and ignore the messages … treat them like any other message and send them back to the user or whatever you might do with a message depending on what you are writing.

I -think- I might know what’'s going on here. Take a look at this:

2007.06.29 09:00:43 aim: Sending packet:

That’‘s from Psi’'s XML console. It was just amongst some other presence packets.

So I haven’‘t the slightest idea why you are not receiving the result stanza. Check your openfire debug logs and see if you can find where it’'s sending the packet. (probably search for type=“result”)

Message was edited by: jadestorm

Hey Daniel,

So I’'m spending some time looking at this now.

I get this when I register for aim with correct details when using psi.

BUT

I get this when I register for aim with incorrect details when using psi

element in it (http://www.xmpp.org/extensions/xep-0100.html#usecases-jabber-login-alt)

I see neither of this in the console on Psi.

Am I missing something super simple? I’'ve emailed you more complete dumps of the xml from the psi console showing that there are no discernible differences that I can see in the XML output.

Mike

That is correct, as I told you before, I can not currently verify that your username and password are correct during the registration process. So as long as you register in a way that doesn’‘t violate a valid “looking” username (ie, you don’‘t enter something that’‘s completely invalid for MSN, like for example you sent something that doesn’'t look like an email address), you will always get a success here.

They’‘re exactly the same. The only difference is the stanza’'s surrounding them - the bad one gets an unavailable presence stanza and the “bad login” message stanza.

As I read in XEP-0100 the stanza on an error should look like this:

See above.

In the alternative on login when it is returned that the details are incorrect a presence stanza with an element in it (XEP-0100: Gateway Interaction)

Now this one I was not aware of until now. GATE-270

Daniel

dayjah wrote:

I see neither of this in the console on Psi.

Am I missing something super simple? I’'ve emailed you more complete dumps of the xml from the psi console showing that there are no discernible differences that I can see in the XML output.

Mike

Hey Daniel,

So I’'m spending some time looking at this now.

I get this when I register for aim with correct details when using psi.

BUT

I get this when I register for aim with incorrect details when using psi

jadestorm wrote:

That is correct, as I told you before, I can not currently verify that your username and password are correct during the registration process. So as long as you register in a way that doesn’‘t violate a valid “looking” username (ie, you don’‘t enter something that’‘s completely invalid for MSN, like for example you sent something that doesn’'t look like an email address), you will always get a success here.

Ahh right, soz I missed that in the previous message.

As I understand it you put the iq stanza in the return list before calling the addNewRegistration code - what if you put the iq “success” stanza after the call to addNewRegistration and the iq “error” stanza in the catch blocks. That way you can return a success and the exception will mean the success stanza doesn’‘t ever go into the returned stanza’'s unless the registration is valid.

That as well as the error element in the presence when signing in will then make you directly in line with XEP-0100

Thoughts?

jadestorm wrote:

That is correct, as I told you before, I can not currently verify that your username and password are correct during the registration process. So as long as you register in a way that doesn’‘t violate a valid “looking” username (ie, you don’‘t enter something that’‘s completely invalid for MSN, like for example you sent something that doesn’'t look like an email address), you will always get a success here.

Ahh right, soz I missed that in the previous message.

As I understand it you put the iq stanza in the return list before calling the addNewRegistration code - what if you put the iq “success” stanza after the call to addNewRegistration and the iq “error” stanza in the catch blocks. That way you can return a success and the exception will mean the success stanza doesn’‘t ever go into the returned stanza’'s unless the registration is valid.

Right, that’‘s what I did in the trunk after you first reported this. =) I think once I get that presence stuff worked out it’'ll be ok. Need to figure out the best way I want to approach that though. Might require a little code restructuring here and there.

Daniel

dayjah wrote:

That as well as the error element in the presence when signing in will then make you directly in line with XEP-0100

Thoughts?

Hi daniel,

Did you get anywhere with this stuff? Is it in beta3? Seem’‘s that my product is getting a different series of notifications from the msn side of the plugin (icq and aim work now) which means I’'m letting MSN users in with bad credentials. This change would make things sooo much easier and more robust.

Mike