Gateway returns malformed message stanzas on registration er
Imported issue was from matt_towers:
I am currently using XIFF to develop a custom xmpp application, running against Openfire with the IM Gateway plugins. As part of my unit testing, I am submitting known bogus credentials to the gateway in order to verify my error handling of this condition. However, it appears that the gateway is returning malformed <message/> stanzas containing the error.
The <message/> stanza that is returned is of type="error" with the <body> element containing the error message (see below for full dump of xml). According to the XMPP Core RFC (section 9.3 "Stanza Errors"), a <message/> stanza that is returned of type="error" MUST contain an <error/> child element. In the case of a failed registration, the IM gateway does not appear to adhear to this requirement.
Additionally, as per the same section in the RFC:
"The receiving or processing entity that detects an error condition in relation to a stanza MUST return to the sending entity a stanza of the same kind (message, presence, or IQ), whose 'type' attribute is set to a value of "error" (such a stanza is called an "error stanza" herein)."
The gateway also appears to be violating this rule with respect to <iq/> queries of type "jabber:iq:register". The stanza that is being sent is of type <iq/> whereas the error response is of type <message/>. There also seems to be a specious <iq/> stanza sent immediately prior to the problematic <message/> stanza.
17:07:07.096 [INFO] OUTGOING:
<iq to="yahoo.localhost" type="set" id="iq_7">
17:07:11.270 [INFO] INCOMING:
<iq type="result" id="iq_7" from="yahoo.localhost" to="unit_tester@localhost/xiff"/>
<message type="error" from="yahoo.localhost" to="unit_tester@localhost">
<body>Yahoo! did not recognize the username you registered with. Please re-register with correct username.</body>
The result of all of this is that the relevant <message/> handler in XIFF throws an exception when the type="error" is encountered without the required <error/> child stanza.
NOTE: The example here is using the Yahoo! gateway but the error appears to hold true for all gateway protocols.
It's not absolutely ideal, but I did update the error code to include an error element.
Imported comment was from matt_towers:
If anyone is running in to this problem with XIFF, here's temporary client-side hack for XIFF to work around the problem. See XMPPStanza::errorMessage() or just grep for "HACK" in the attached file.
File Added: XMPPStanza.as
Imported comment was from matt_towers:
Thanks for the reply. I'll hack around it in XIFF for now. While slightly non-standard, if the <error/> tag is included XIFF will handle the situation just fine.
There's actually already an issue filed for this. One of those things I simply have not had time to do anything about yet. =)
The latter is actually something different – the thing is, there's no good way (currently) to detect that the username and password you submitted for the Yahoo service was right or wrong during the registration process. The best you can do is log the user in and that is not a good idea as others would see that the user is logged into Yahoo and perhaps try to message them. Well the client is still in the process of handling the registration in the first place and there's a good chance it will not be willing to handle the situation. The Gateway XMPP extension discussions this situation a little bit. The current solution that's often used (and used by me) is to always report success for the registration. This is effectively legit in that you have indicated "yes, you have registered with this service". That doesn't mean that the data you submitted is correct, it just means yes you were successful in registering.
The XEP suggestions, and I agree with but haven't implemented yet, basically doing this:
1. receive username and password registration
2. try to log the user into the legacy service, if failed, immediately return a registration error
3. if success, hold onto that session with the expectation that 9 out of 10 times a registration is followed by a "Yes i want to log in", so you hold onto the session with the assumption that they will soon "attach" to it, holding onto incoming messages and such in the process
4. if no login follows, wait for a set period of time before auto-logging them out of the legacy service. (this requires making a record of messages and such that had come in and being sure to pass them on later)
This process is complex, and is not easily wedged into the existing code. So while it's on the list, other things are higher in the priority list than it.
But the lack of including the error tag is an issue that should be far easier to take care of and hence I hope to have it taken care of sooner. Your post is far more informative data wise than the other issue I have if I recall correctly. Not going to close either of them for now, will likely just close them together when the issue is solved.
BTW the latter issue with the registration working but then failing when you actually log in is also in another open issue. =)