I have a running ejabberd installation, with http-bind enabled, nginx proxy, and a mini jappix xmpp client for web browsers. I also have an external authentication program.
I can connect the same user on this server with different ressources if I use the classical 5222 port. But:
If I have active sessions from classical xmpp clients for a given user I cannot connect this user with http-bind (401 authentication failure).
I the first connection is made via http-bind no other connection can be done by other classical xmpp clients (and resources are of course different). I sometimes get the 401 already connected message
I can only connect the same user in one browser, I cannot connect the same user several time on http-bind (resources are different on theses connections, but I also get a 401)
I'm sure the external authentification program is never launched when I get theses auth failure
max_user_sessions settings are ok (tested with infinity), and if I'm not connecting in http-bind I can run parallel sessions. But in case of I also tested the new resource_conflict setting values without any success (and it's not a re'source conflict in fact)
installation: ejabberd-2.1.10 Debian (from ejabberd-2.1.10-linux-x86-installer.bin, also tested in x86_64 version).
So is this a "feature" in http-bind ? making it the only valid Resource for a given user while activated? And how to run several http-binded sessions for the same user if so? Any hints?
I think I know why... my external auth script is handling a token based authentification where the password may differ for the same user on parallel sessions, the authcah is quite cerainly caching the password, which is not OK for further sessions. It would need a fallback on external auth after a caching auth failure.
Problem disappear If i
Problem disappear If i set:
{extauth_cache, false}.
But this seems to prevent my shared_roster behavior now.
The question is why the extauth_cache is preventing further login with the same user on other resources when I come from http-bind first?
I think I know why... my
I think I know why... my external auth script is handling a token based authentification where the password may differ for the same user on parallel sessions, the authcah is quite cerainly caching the password, which is not OK for further sessions. It would need a fallback on external auth after a caching auth failure.