This is intended for use in conjunction with the ejabberd external auth script provided here:
If anyone wants to add this to their instance setup, feel free to hit me up. After talking @M0YNG through the https://mastodon.radio deployment recently I think I've got a good start on putting together a proper guide.
On an incidental point, how do #ejabberd external scripts handle usernames or domain parts with colons in it?
Regardless of what this post from 2009 says (http://lists.jabber.ru/pipermail/ejabberd/2009-April/004886.html), I do not see any limitation to having colons in the local part, and the domain part can be an #IPv6 which by definition has lots of colons. #RFC7622 refers.
Mastodon last I checked only allows letters, numbers and underscores in usernames so there should be no invalid JID possible on that side.
Domains probably can't reasonably be expected to be raw IPv6 addresses due to the importance of SSL on most layers, it'd be a weird edge case I don't think is worth considering.
I wasn't asking about your use case specifically but about the #ejabberd external auth implementation generally. Seems to be a serious hole in there. In certain cases it might be possible to hijack an account by changing its password or to delete an account to which you have no access.
Instead of a separator it should use length prefixed fields.
@0 as far as I'm aware, the restricted character list hasn't changed, they can't be in a valid JID unescaped.
I guess if there's a flaw in ejabberd it's possible. The script only takes input from ejabberd itself so if there's a flaw in the JID validation process there it could theoretically be an attack vector.
You'd have to talk to an ejabberd dev about that. All I know is the strings passed to the script are validated to a degree beforehand, they are NOT raw strings from the client software.
> as far as I'm aware, the restricted character list hasn't changed, they can't be in a valid JID unescaped.
What is your reference for that? From what I can see they're perfectly valid.
I'm away from the computer already but when time permits I'll run a practical test.
@0 RFC7622, section 3.3.1.
Indeed I was completely blind to § 3.3.1.
@stevenroose @M0YNG @NGIZero Masto can do some external auth, LDAP would be a good common option for both sides - but in that case you'd end up also needing your own external methods for user registration, account management, password changes etc.
It's a viable option for a closed system, like a company or small org that already has something like that in place. Would be quite a job shifting an established standalone instance to a setup like that.
Consider this a friendly, local pub. Make yourself at home, bring your friends, have a good time! Meet new people, have a laugh, enjoy the ambience, and the Oxford commas.