powered by Jive Software

Critical bug still not fixed since more than 6 months

Hello,

When will you release a bug fix for this bug ? I want to restart our jabber project for an important Web community and this bug make Openfire unusable. If this bug cannot be fixed, I will not have no other choice to use another Jabber server :(.

Thanks !

hello ??

Blanking out any passwords, and changing hostnames if you need to, would you mind sharing your openfire config? I’m having trouble following what the scenario is. I think looking at your config would help me understand what you are doing and what the problem might be.

My general understanding is that you are doing authentication against a custom database. Simple enough, except that it sounds like you are saying that if the user is -not- in the actual Openfire user database, that you get an anonymous username automatically.

Am I also to assume you are not using JDBCUserProvider? (if not, why? ie why not also pull your users directly from the same database you are pulling the auth stuff from) Just FYI in case you didn’t know about it: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/ org/jivesoftware/openfire/user/JDBCUserProvider.html

I don’t have the original configuration file. I recently tested again with a new version (3.4.2) and the problem is little different. Only Pidgin with a special configuration (use old ssl, port 5223, allow clear text) works. Login with Gajim or Adium all fails (cannot logon at all, no anonymous login anymore).

I’m not using JDBCUserProvider, because I just want to provide authentication against my existing database. I want my users to be free to set their vcard as they want (except their password, so I disabled the password change in the Openfire configuration). Openfire have a read-only access on this database and cannot gain rw access.

I attached a copy of my Openfire configuration.

Thanks !

The user provider isn’t the same as the vcard provider though. The user provider provides to openfire the list of available/valid users and possible minor information about them. The VCards (stuff the user can customize) are handled by a different provider. (which it looks like there’s no jdbcvcardprovider at all, but maybe that’s for the best, and you don’t want/need that anyway) I think you probably need to use the JDBCUserProvider to tie into your database so that Openfire knows what users are valid. It won’t affect your user’s ability to update their vcards.

My guess, without looking at the code, is that what’s happening is that openfire is getting a valid auth from your auth provider settings, and then looking if it’s a valid user (user provider) and not finding them. So it says “uhm… they’re authing ok… but no account … lets let them in, best we can do is create an anonymous account”. In other words, I think it’s an expected behavior. Would you mind trying the user provider out and doing some testing? I really think that it will solve your problems -and- will continue to allow your users to set vcard information.

Hello,

I added the JDBCUserProvider, but this do not work better. Still work only with Pidgin.

This is my debug log (i cleared it, i tried to connect with Gajim and then I copied the log into this post.

at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:577)
at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:226)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:280)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:156)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:173)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: org.jivesoftware.openfire.user.UserNotFoundException
at org.jivesoftware.openfire.net.XMPPCallbackHandler.handle(XMPPCallbackHandler.java:75)
at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:568)
... 18 more
2008.01.15 04:40:10 XMPPCallbackHandler: RealmCallback: mydomain.org
2008.01.15 04:40:10 XMPPCallbackHandler: NameCallback: homer
2008.01.15 04:40:10 SASLAuthentication: SaslException
javax.security.sasl.SaslException: DIGEST-MD5: IO error acquiring password [Caused by java.io.IOException: org.jivesoftware.openfire.user.UserNotFoundException]
at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:577)
at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:226)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:280)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:156)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:173)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: org.jivesoftware.openfire.user.UserNotFoundException
at org.jivesoftware.openfire.net.XMPPCallbackHandler.handle(XMPPCallbackHandler.java:75)
at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:568)
... 18 more

Could you share your updated openfire.xml with the user provider settings that you added?

My new openfire.xml.

Just to get a feel for things and eliminate possible issues …

searchSQL is busted SQL as i ends with an AND without anything following it

I notice in all of the user SQL blocks that you use status != 0, whereas you don’t use that in the auth provider. Any particular reason why?

Also, I don’t know for certain, but but the user provider -may- punt to the default user provider if any of those SQL queries fail. I don’t know if that’s the case, but it’s a possibility.

I didn’t used it in authprovider by mistake. I just added it now (adding it change nothing).

My searchsql is ending by AND, because in the doc, the example is

SELECT user FROM myUser WHERE[/b]

(removing this leading AND change nothing too)

Hrm, yeah, you might be right, it must be simply constructing the SQL on the fly.

Well, I mean, all I can do now is attempt to try it on a database of my own to see if it works correctly or not on my end.

It’s hard to know what’s going on without being able to see your database, know what you are typing, watching openfire do it’s thing on the fly, that sort of thing. Hopefully I can reproduce the behavior locally.

I tested all my queries with phpmyadmin (by replacing the ? with my login without the @domain.tld) and all works and return the requested data.

The debug log seem to indicate something wrong with sasl when I logon with Gajim.

So, if my configuration file seem good, I assume this is an unresolved bug since more than 6 months …

No developers are looking at this forum ?

I use Openfire on another installation but with the LDAP connector and no problems. The problems appear only with the SQL connector. Am I the only one who use that ?

chuckle I happen to be one of the developers. But I will need to be able to reproduce it before I can fix it.

eh

Don’t hesitate to ask me more info if you need !

So this is interesting, I’d like you to test this if you don’t mind. Do you have -any- other fields in your database epiknicks that could be used as a full name? Even something that doesn’t make sense for the moment. I ran into an odd behavior in my own setup. I had a table with only user and password in it. I set name and email to user as well as username to user. for some reason, this caused the provider to not work at all. (definitely a bug IMO) – unless the problem is that email doesn’t look like an email address. I’m not aware of it actually checking that.

I’m not doing any left joins in mine. Theoretically that shouldn’t matter.

I don’t suppose you’d mind sharing the constructs of your databases with me and maybe a couple of sample entries with passwords XXX’d out and anything sensitive?

Interestingly enough, I’ve yet to see anything that gave me an anonymous account.

Hello,

Changing the fullname field change nothing.

I send you my database schema in PM.

Thanks !

Any news ?

hello ??