JDBCAuthProvider and non-plaintext

Openfire Openfire Dev
1

Well, I believe I finally got Wildfire authenticating against my Drupal users table, which uses MD5 password hashes. However, I had to make a couple changes to JDBCAuthProvider to get this to work.

First, on line 89, the parsed PasswordType wasn’'t being assigned to the passwordType variable, so I added this assignment.

I also removed lines 164-166, which threw an exception if the authentication type was not plaintext.

After these changes, I seem to be able to authenticate using the gnome-jabber client (although gaim 1.5 still acts funny), but it would be great if someone could verify that these changes are correct. They seem to fit in with the rest of the scheme, as if they were simply oversights which slipped through the cracks, but I’‘m pretty new to Wildfire still, so I’'d certainly like some confirmation if anyone can offer it

Thanks,

noah

P.S., here’'s a Subversion diff showing exactly what I did:

Index: JDBCAuthProvider.java

===================================================================

— JDBCAuthProvider.java (revision 4640)

+++ JDBCAuthProvider.java (working copy)

@@ -86,7 +86,7 @@

passwordSQL = JiveGlobals.getXMLProperty(“jdbcAuthProvider.passwordSQL”);

passwordType = PasswordType.plain;

try {

  •        PasswordType.valueOf(JiveGlobals.getXMLProperty("jdbcAuthProvider.passwordType" , "plain"));

  •        passwordType = PasswordType.valueOf(JiveGlobals.getXMLProperty("jdbcAuthProvider.passwordType" , "plain"));

}

catch (IllegalArgumentException iae) {

Log.error(iae);

@@ -161,9 +161,6 @@

public String getPassword(String username) throws UserNotFoundException,

UnsupportedOperationException

{

  •    if (!supportsPasswordRetrieval()) {

  •        throw new UnsupportedOperationException();

  •    }

String password = null;

Connection con = null;

PreparedStatement pstmt = null;

2

Noah,

I actually made a series of fixes to the class (with Jorge’‘s help) today. You found the same two bugs that we did, although my fix is a bit different. Tomorrow’'s daily build should work much better.

Regards,

Matt

3

Noah,

BTW, would you be willing to write up a quick guide about integrating Wildfire with Drupal? I think it could be quite useful. Perhaps we could even get it published on the Drupal site.

Regards,

Matt

4

Matt,

Things are working much better with your new fixes. As far as writing a guide for Wildfire-Drupal, I’‘d be happy to do so; however, I’‘d prefer to wait a little bit until I’‘ve got things working better for sure. And of course, both Drupal and Wildfire can use multiple backends: MySQL, PostgreSQL, even LDAP, but a basic guide using the MySQL table (Drupal’‘s most common setup) should be no problem. I still need to get the user profile data integrated between the two, and test with more clients to see if I can actually get the chat working smoothly, but as soon as I get things working more squarely, I’'ll get to work on the guide.

Thanks for all your help,

noah

5

This post is over a year old, but I still see the issue in JDBCAuthProvider class.

This is related to a post I did yesterday discussing this class and SASL authentication.

It would be great if one of the development team clarified the whole situation.

In particular how DIGEST-SASL is achieved when you store passwords hashed in the db (openfire’s or external with JDBCAuthProvider)

6

I seem to be dealing with EXACTLY the same issue now.

I posted a ticket in their bug tracking system back in November JM-1186

Today, I emailed Jive Software about this issue hoping to get it resolved. I’ll respond to my email to them mentioning this thread. Thanks for finding this issue, camclive.