Agreed, the SCRAM RFC notes escaping those chars in the username and
some other bits, but not the password. Looks like the original 0-x
client changes in QPID-5878 contained the issue which was later
carried over to to the 1.0 client in QPIDJMS-150 and so both are
affected.

I've yet to try it out but I assume we just need to do something like this:

--- 
a/qpid-jms-client/src/main/java/org/apache/qpid/jms/sasl/AbstractScramSHAMechanism.java
+++ 
b/qpid-jms-client/src/main/java/org/apache/qpid/jms/sasl/AbstractScramSHAMechanism.java
@@ -69,7 +69,7 @@ abstract class AbstractScramSHAMechanism extends
AbstractMechanism {
             throw new SaslException("Request for initial response not
expected in state " + state);
         }
         StringBuilder buf = new StringBuilder("n=");
-        buf.append(saslPrep(getUsername()));
+        buf.append(escapeUsername(saslPrep(getUsername())));
         buf.append(",r=");
         buf.append(clientNonce);
         clientFirstMessageBare = buf.toString();
@@ -221,6 +221,10 @@ abstract class AbstractScramSHAMechanism extends
AbstractMechanism {
             throw new SaslException("Can only encode names and
passwords which are restricted to ASCII characters");
         }

+        return name;
+    }
+
+    private String escapeUsername(String name) {
         name = name.replace("=", "=3D");
         name = name.replace(",", "=2C");
         return name;


On 6 October 2017 at 14:08, Lorenz Quack <[email protected]> wrote:
> I might have been to hasty in my response.
> SCRAM SASL only requires the encoding for the username. Not for the password.
> So the broker behaviour seems correct.
>
> The JMS client encodes username AND password which seems to cause the issue.
>
> Kind regards,
> Lorenz
>
>
> On Fri, 2017-10-06 at 14:02 +0100, Lorenz Quack wrote:
>> Hi,
>>
>> I think this is a broker issue.
>> At least for the SCRAM authentication provider.
>> Vavricka, could you confirm that you are using a SCRAM authentication 
>> provider on the broker?
>>
>> In SCRAM "=" and "," are specially encoded in usernames and passwords.
>> It looks like the broker is doing this encoding for the username but fails 
>> to do it for the password.
>>
>> I raised JIRA QPID-7961 [1]
>> Thanks for finding this, Vavricka.
>>
>> [1] https://issues.apache.org/jira/browse/QPID-7961
>>
>>
>> On Fri, 2017-10-06 at 13:30 +0100, Robbie Gemmell wrote:
>> >
>> > In terms of the client, my answer here is largely the same as the
>> > other recent thread. I gave the client a check with a tweak of the
>> > same brokerless test I mentioned last time and all was again fine. As
>> > mentioned however, that test uses PLAIN, so maybe its an issue with
>> > another particular SASL mechanism on the client or the broker (or
>> > both), or perhaps the broker doesnt like credentials in that form. I'd
>> > guess SCRAM-SHA-256 could be getting used with this combination of
>> > client+server, but it depends on your precise client and broker
>> > configuration, as perhaps might whether the credentials will work.
>> > Again, perhaps a look with wireshark could help reveal something.
>> >
>> > Robbie
>> >
>> > On 6 October 2017 at 12:40, Vavricka <[email protected]> wrote:
>> > >
>> > >
>> > > Hi,
>> > >
>> > >  it looks like there are two characters which cannot be used in password.
>> > > These characters are comma and equals.
>> > >
>> > >   Qpid JMS Client - 0.25.0
>> > >   Qpid Java Broker - 7.0.0
>> > >
>> > >  Connection string
>> > > amqp://host:port?jms.username=user&jms.password=encodedPassword
>> > >
>> > >  I am encoding password by URLEncoder.encode(password,
>> > > StandardCharsets.UTF_8.name()).
>> > >
>> > >  Are these characters unsupported?
>> > >
>> > >   Vavricka
>> > >
>> > >
>> > >
>> > > --
>> > > Sent from: 
>> > > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [email protected]
>> > > For additional commands, e-mail: [email protected]
>> > >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to