Because of the condition "c >= 32", Smack would possible return a
c-nonce containing ASCII whitespace characters (32d, 0x20), which are
not allowed in the c-nonce as per RFC 5802.
This commit applies the correct condition: "c > 32".
Fixes SMACK-735.
This adds the ability to provide a distinct authorization identifier for use
by SASL mechanisms. Not all SASL mechanisms support this operation, in
particular CRAM-MD5.
Both the javax and provided SASL implementations are extended, and an authzid
parameter added to the authenticate method.
The authorization identifier is passed as a EntityBareJid in order to assure the
correct form.
Resolves SMACK-677.
Minor-Modifications-By: Florian Schmaus <flo@geekplace.eu>
Otherwise we may get an NPE if the key was cached:
Connection closed with error java.lang.NullPointerException: Attempt to get length of null array
at org.jivesoftware.smack.util.stringencoder.Base64.encodeToString(Base64.java:43)
at org.jivesoftware.smack.sasl.core.SCRAMSHA1Mechanism.evaluateChallenge(SCRAMSHA1Mechanism.java:201)
at org.jivesoftware.smack.sasl.SASLMechanism.challengeReceived(SASLMechanism.java:230)
at org.jivesoftware.smack.SASLAuthentication.challengeReceived(SASLAuthentication.java:328)
at org.jivesoftware.smack.SASLAuthentication.authenticated(SASLAuthentication.java:347)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPConnection.java:894)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:909)
at java.lang.Thread.run(Thread.java:818)
Thanks to Stefan Karlsson for helping with the implementation.
Also add SASLMechanism.checkIfSuccessfulOrThrow(), to increase the
security by verifying the mechanisms state at the end of SASL
authentication.
SASLMechanism now has a SASLPrep StringTransformer.
Refactor SHA1 functions out of StringUtils into SHA1 utility class.
Add MAC utility class.
Make DummyConnection getSentpacket() methods use generics to make unit
testing SCRAM-SHA1 easier.
Fixes SMACK-398
Florian Schmaus
Dave Cridland