Authenticate(username, password) being passed a domain'less username?

Hi All,

Just installed openfire today, and been trying to get any of the auth plugins but mainly the pop3 plugin. After playing around for hours, I got eclipse attached / debugging and could see authenticate(String username, String password) was being passed strictly username, not username@domain.com. I’m not a Java developer so I’m not exactly sure what could be causing this, since it appears each auth provider checks for “@” being present (Default, Pop3, JDBC).

Anyone have any ideas, hit a big road block with this, I’d assume this isn’t a bug, but a mis-configuration, but I’ve tried tweaking things and gotten no where fast.

Here’s my config

hybridAuthProvider.primaryProvider.className
org.jivesoftware.openfire.auth.DefaultAuthProvider
hybridAuthProvider.primaryProvider.overrideList
admin
hybridAuthProvider.secondaryProvider.className
org.jivesoftware.openfire.auth.POP3AuthProvider
provider.admin.className
org.jivesoftware.openfire.admin.DefaultAdminProvider
provider.auth.className
org.jivesoftware.openfire.auth.HybridAuthProvider
provider.group.className
org.jivesoftware.openfire.group.DefaultGroupProvider
provider.lockout.className
org.jivesoftware.openfire.lockout.DefaultLockOutProvider
provider.securityAudit.className
org.jivesoftware.openfire.security.DefaultSecurityAuditProvider
provider.user.className
org.jivesoftware.openfire.user.DefaultUserProvider
provider.vcard.className
org.jivesoftware.openfire.vcard.DefaultVCardProvider

Any pointers would be a great help, trying to watch one of the plugins in full action so I can write my own to connect to the CMS provider I’m presently using.

Thanks!!

Openfire does only support a single XMPP domain. The auth providers just strip the domainpart (which should be done one layer higher, there is no need that every auth provider does this, but that’s a design issue).

Hi Flow,

Just to make sure I’m understanding, USERNAME, and not USERNAME@DOMAIN is intended behavior there fore

if (username.contains("@")) {

// Check that the specified domain matches the server’s domain

int index = username.indexOf("@");

String domain = username.substring(index + 1);

if (domain.equals(XMPPServer.getInstance().getServerInfo().getXMPPDomain())) {

username = username.substring(0, index);

}

} else {

// Unknown domain. Return authentication failed.

throw new UnauthorizedException();

}

In each of the providers should be removed, to prevent UnauthorizedException from always being thrown?

Thanks!!

That’s a nice example of a dangling else. Where is the snippet from? I can not tell to which if condition this is the else case. The two providers I’ve taken a quick look at DefaultAuthprovider and LdapAuthProvider don’t throw an UnothorizedException if the username does not contain a ‘@’ character.

public void authenticate(String username, String password) throws UnauthorizedException {

if (username == null || password == null) {

throw new UnauthorizedException();

}

if (username.contains("@")) {

// Check that the specified domain matches the server’s domain

int index = username.indexOf("@");

String domain = username.substring(index + 1);

if (domain.equals(XMPPServer.getInstance().getServerInfo().getXMPPDomain())) {

username = username.substring(0, index);

}

} else {

// Unknown domain. Return authentication failed.

throw new UnauthorizedException();

}

This was from Pop3 provider, this logic seems to also be in the JDBC?

The logic is more or less flawed. I don’t think it makes sense to throw an UnauthorizedException in case the username does not contain an ‘@’ character.