Spark 2.0.1 with unusual passwords

I have an account that cannot log in to our server using Spark 2.0.1. The same account can log in using other clients such as GAIM and other accounts can log in using the client with the same settings. The account has unusual characters in the password. The message received upon the login attempt is “Invalid username or password” and stderr displays the same stack trace as when an incorrect password is entered (SASL authentication failed: at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 204)).

Note that this is a separate bug from the one described here:

http://www.jivesoftware.org/community/message.jspa?messageID=113370#113370

That issue was fixed with Spark 1.1. However, since alt-port SSL does not work in Spark 2.0.1, I don’‘t know how to create an environment that allows me to intercept and analyze the network traffic between the client and the server, so I don’'t know what Spark is sending that differs from GAIM.

Can you give us a password to test that doesn’'t work?

Thanks,

Matt

Sure, the following two passwords don’‘t work: “foo " and " foo”. That is, passwords with leading or trailing whitespace don’'t work with Spark. Embedded whitespace seems to work OK, including multiple consecutive whitespace characters.

GAIM allows non-StartTLS connections, so I was able to trace what traffic it sends for successful authentication. GAIM 1.5 uses SASL with the PLAIN mechanism and it encodes the authentication data correctly, with the leading space or trailing space included (so it is not subject to any XML whitespace munging). I can’'t determine what Spark 2.0.1 is sending, but I recall that Spark 1.x did not use SASL PLAIN authentication. Given this, the problem may actually be server-side in that the server does not consider leading/trailing whitespace within the element data significant (depending on whether the whitespace is being sent by Spark, which I cannot determine). The server is Wildfire 3.0.1.

Hi,

there’'s also JM-560 but this should have little to do with the issue you see.

Maybe someone can point out which JEP does not allow ‘’ ‘’ within a password.

LG

I filed SPARK-362 for this issue.

Regards,

Matt