powered by Jive Software

HybridAuth problem/bug: changing passwords

My current setup has hybridauth authenticating first from the windows domain(nativeauth) and second from the default DB(defaultauth) (i tried reversing the order to no avail). Trying to change a user’'s password throws an exception.

I’‘m quite comfortable with not being able to change a domain password, that’‘s what the rest of the domain is for, but i’‘m concerned that my only method for changing a user’'s password is going to be editing the database and then bouncing the server.

Is there any way this can be worked around? does password changing work for any non-defaulth auths? perhaps a property to disable trying to change passwords on a per-authtype basis: ie: hybridAuthProvider.secondaryProvider.updatepasswords=false

the exception is below for reference.

Exception:

java.lang.UnsupportedOperationException

at org.jivesoftware.wildfire.user.NativeUserProvider.setPassword(NativeUserProvide r.java:28)

at org.jivesoftware.wildfire.user.User.setPassword(User.java:102)

at org.jivesoftware.wildfire.admin.user_002dpassword_jsp._jspService(user_002dpass word_jsp.java:87)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)

at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:822)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:43)

at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)

at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler. java:494)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:569)

at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)

at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.ja va:624)

at org.mortbay.http.HttpContext.handle(HttpContext.java:1434)

at org.mortbay.http.HttpServer.service(HttpServer.java:896)

at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)

at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)

at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)

at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)

at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:366)

at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)

/code

The issue is a little more complicated. Let me try to explain:

The native auth attempts to authenticate the user against the windows domain. If it is succesful, the database is checked to see if there is a user. If there isnt a new user is created in the database, the password is set to an arbitrary string. You are using hybridauth so if it to authenticate against the domain then your secondary auth method is called, in this case being defaultauth.

Now the problem exists because there is no “hybriduserprovider” in other words, because you are using the nativeuserprovider ALL password changing is blocked. Thats basicly what this provider does is throw an exception anytime anyone trys to change their password.

A possible solution to your problem would be to change to the DefaultUserProvider. This will allow both your natively authenticated users and your defaultauth users to change their passwords. Though since the native users authenticate against the windows domain and not the database, their changing their passwords would have no result except that their native passwords would then be proliferated to the database which could be a slight security issue. If you wanted to prevent this, a small change to the code would likely fix this, let me know if you are intrested and I could help you out.

Hope that helps,

Alex

the only passwords i’'m worried about changing through wildfire are the non-domain ones.

How would i configure the scenerio that you speak of?

thanks

jerm

You aren’‘t actually changing the passwords so to speak since the authentication mechanism is refering to the windows domain and not the database to authenticate a user. The problem arrises because if one of those users who use the windows domain attempt to change their password it isn’'t actually being changed… its just being put in the database and since they are authenticating against the windows domain it doesnt matter.

Alex

oh, gotcha… my users are very rarely savvy enough, and never willing enough to change their passwords of their own accord unless they’‘re prompted for it, so i’'m on with that.

So how do i make this fallback technique work w/o hybrid?

What do you mean?

Alex

i mean… what would the setup be in the config file to do what you’'re suggesting?

my understanding is that you need hybridauth in order to have the fallback to a secondary auth method should the first fail, but that i can’'t use hybridauth because password changing is disabled.

a pseudo-code snippet of the relevant section inthe config file would be great

thanks

Password changing isn’'t handled by the authentication mechanism you need to change your UserProvider to the default userprovider. This is in the wildfire.xml. Just remove the user provider from the configuration and it will switch back to the defualt provider.

Alex

hmmm… my configuration used to look like this

/code

that worked well for everything except changing passwords. domain auth and db auth worked fine

If i change userprovider to default or remove it all together, i can only authenticate off of the database and i get the following warning when i try to login with a domain user:

2006.01.18 17:25:01 SaslException

javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Mismatched response.

at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(Unknown Source)

at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(Unknown Source)

at org.jivesoftware.wildfire.net.SASLAuthentication.doHandshake(SASLAuthentication .java:192)

at org.jivesoftware.wildfire.net.SocketReader.authenticateClient(SocketReader.java :309)

at org.jivesoftware.wildfire.net.SocketReader.readStream(SocketReader.java:270)

at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:119)

at java.lang.Thread.run(Unknown Source)

/code

any idea?

thanks again

jerm

Hmmm… Maybe someone else would have some insight into this, I am not sure whats happening. I will look into the code tonight and see if I see what would cause this. Or perhaps someone might have a better sugesstion on how to fix it.

bump… any recent insights?