Hi, what are you trying to do? In the newest version at https://github.com/Leberwurscht/friendica-addons/network there is already a prototype for eJabberd extauth functionality, is this what you mean?
If your JID changes, the internal list of jabber addresses should be emptied (remove all entries with jappixmini, id:% in the pconfig table for the correspondig user). Then, the new address should be told to your contacts within ten minutes. Otherwise, it may take a week.

This is what I meant, I guess I'm late :)

I'll try your prototype.

Actually it's not exactly what your version does.

So what did you imagine? Or is there a bug?

The external authenticator I'm working on is not supposed to work with Friendica's user/pass (though it whould trivial to add once working), but with some temporary password generated on both JappixMini's and eJabberd's sides. So, with only a slight modification of the jappixmini plugin, it would allow my instance's users to connect automagically to eJabberd, without having to enter their passwords or anything.

It does not generate a temporary password, but you can authenticate either with the Friendica password, or with the session id (format for the password is "PHPSESSID=..." in this case).
Users don't need to make any configuration - in fact the user configuration is disabled if the admin activates this functionality. See https://friendica.mafiaspiel.org/display/leberwurscht/37762

So Friendica uses PHPSESSID as password, that's it? I guess it's better than what I had in mind then...

Yes, PHPSESSID is used as password. But you can still authenticate with your Friendica password, so that you can use an external Jabber client.
I think the code is not ready to be pulled into the official repository yet unfortunately, but I want to try to find some time to get this done soon.

Ok, that's mostly what I had in mind, so feel free to ask if you need testers.

Ok, @Leberwurscht Brot . My own extauth implementation finally works a little. Still no-one populating my roster, but that should be a whole other problem.

I just wonder how your implementation works. How does the extauth script know the PHPSESSID provided by ejabberd (from jappixmini) is good?

The extauth script opens /jappixmini/extauth?extauth=auth&username=... and sends along the PHPSESSID cookie.
/jappixmini/extauth uses Friendica's local_user() function to check whether this session id is valid for the given username and returns the result to the extauth script.

Wouldn't that force eJabberd to be on the same host as Friendica?

No, it does not call /jappixmini/extauth but http://site_address/jappixmini/extauth, sorry!

No offense, I'm just trying to weigh the flaws and virtues of our two approaches. Mine is clearly a little more CPU intensive (computhing hashes now and then), but then doesn't need any communication between the extauth script and Friendica. At least until we connect with a real user/pass, then we need to connect its database. Your solution tends to remove a bit of complexity on Friendica's side, at the expense of a little more complex extauth. And I'm not sure I'm easy with eJabberd calling potentially failing scripts as extauths.

It's a little messy in my head, though ;)