JDBCAuthProvider does not play nice with SCRAM
Description
When Openfire is configured to use a custom JDBC integration, the recently added SCRAM implementation causes problems (without a salt, it tries to reset a password, which can be read-only through the provider - if the password is not read-only, the newly generated password will probably be unusable by other systems, as it was regenerated with a salt only in the Openfire database)
I'm seeing this in SASLAuthentication#getSupportedMechanisms():
Should this be an "or" condition instead, perhaps combined with a change where JDBCAuthProvider#isScramSupported returns 'true' only when its fields allowUpdate == true and setPasswordSQL != null. Again, I'm not sure if resetting a password value outside of the Openfire is wise, when the salts used are not in that same database.
Environment
Acceptance Test - Entry
Activity
This is a critical problem for our deployment, which version is the first this affects? Any timeline for 4.1.0 and/or a hotfix?
Anything I can do to help?
To clarify, we have a database with usernames and plaintext passwords (random strings created by us for internal use) and cannot auth anyone logging in with 4.0.3 - a workaround would be just as good as a fix for our purposes
Thanks
Did you find a workaround for this, or is it fixed in 4.1.0 Beta?
In my case, I had to add a system property "sasl.mechs" to "PLAIN" to have it auth properly, so this appears to be fixed I suppose - not sure about the person who initially had the problem, but things are working for me.
No, that's a workaround, but I think the suggested fix is right. PR made.
Assignee
Reporter
Labels
Expected Effort
Ignite Forum URL
Fix versions
Priority
