Mod Auth Http Async + Jitsi-Meet


I am trying to configure prosody to use mod_auth_http_async with jitsi-meet.

I’m using the instructions from here:

And I have used it successfully in the past with mod_auth_external, which provides ‘plain’ auth.

Now I am trying to use mod_auth_http_async:

Unfortunately Strophe chokes when logging in because no auth mechanisms are provided inside _connect_cb:

        var matched = [], i, mech;
        var mechanisms = bodyWrap.getElementsByTagName("mechanism");
        if (mechanisms.length > 0) {
            for (i = 0; i < mechanisms.length; i++) {
                mech = Strophe.getText(mechanisms[i]);
                if (this.mechanisms[mech]) matched.push(this.mechanisms[mech]);
        if (matched.length === 0) {
            if (bodyWrap.getElementsByTagName("auth").length === 0) {
                // There are no matching SASL mechanisms and also no legacy
                // auth available.

Basically it’s hitting the _no_auth_received since there are no matching SASL mechanisms.

When using mod_auth_external, which provides ‘plain’ auth as opposed to ‘plain_test’, I see a response of something like:

<body xmlns:stream='' xmpp:version='1.0' xmlns:xmpp='urn:xmpp:xbosh' ver='1.6' inactivity='60' requests='2' polling='5' secure='true' hold='1' from='' authid='60ac366e-7a82-4f3b-adc1-24d579448e12' wait='60' sid='60ac366e-7a82-4f3b-adc1-24d579448e12' xmlns=''><stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms></stream:features></body>

Notice the stream features with a list of hash mechanisms:

<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms>

And when using mod_auth_http_async, I get something more like:

<body xmlns:stream='' xmpp:version='1.0' xmlns:xmpp='urn:xmpp:xbosh' ver='1.6' inactivity='60' requests='2' polling='5' secure='true' hold='1' from='' authid='8a0afb07-9d81-4409-a823-be667edca2e8' wait='60' sid='8a0afb07-9d81-4409-a823-be667edca2e8' xmlns=''><stream:features/></body>

Notice the <stream:features/>

As far as I can tell, plain_test in prosody just provides a plain text password, and when you provide plain: it doesn’t present the password, but just the username and expects it to look up and return the plain text password for the provided user.

Is there some way to support MD5 and SCRAM for plain_test, or maybe to allow lib-jitsi-meet/strophe to provide the plain-text password, without needing one of these underlying mechanisms?

Ultimately they’re going to be going over HTTPS/BOSH.

Any help here would be greatly appreciated!


Configure your virtual host with

If that still doesn’t work there is one for ‘consider bosh secure’ … I don’t remember the exact config, I need to look it up when I’m at the computer.


It is consider_bosh_secure = true.

The thing is that the bosh connection is proxied from the web server and the proxy is over http, and prosody consider this as unsecure and do not allow authentication to go over it, but this is not true as the link is over https which prosody doesn’t know about :slight_smile:


Thanks for helping with this @damencho

Here is the VirtualHost for my auth VirtualHost:

VirtualHost ""
        -- enabled = false -- Remove this line to enable this host
        authentication = "http_async"

        -- Properties below are modified by jitsi-meet-tokens package config
        -- and authentication above is switched to "token"
        -- Assign this host a certificate for TLS, otherwise it would use the one
        -- set in the global section (if any).
        -- Note that old-style SSL on port 5223 only supports one certificate, and will always
        -- use the global one.
        ssl = {
                key = "/etc/prosody/certs/";
                certificate = "/etc/prosody/certs/";
        -- we need bosh
        modules_enabled = {
            "ping"; -- Enable mod_ping

        c2s_require_encryption = false
        consider_bosh_secure = true

I added in the ‘consider_bosh_secure’ line, but I am still seeing the request come back without any auth mechanisms:

"<body xmlns:stream='' xmpp:version='1.0' xmlns:xmpp='urn:xmpp:xbosh' ver='1.6' inactivity='60' requests='2' polling='5' secure='true' hold='1' from='' authid='e5445e18-b05d-4713-9a9d-5eeb1ae91618' wait='60' sid='e5445e18-b05d-4713-9a9d-5eeb1ae91618' xmlns=''><stream:features/></body>"

The error coming back from lib-jitsi-meet is specifically:

Logger.js:125 [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>:  UnhandledError: null Script: null Line: null Column: null StackTrace:  Error: Strophe: Server did not offer a supported authentication mechanism
    at Object.i.Strophe.log (strophe.util.js:89)
    at Object.error (strophe.js:2083)
    at s.Connection._no_auth_received (strophe.js:3851)
    at s.Connection._connect_cb (strophe.js:3940)
    at e.Bosh._onRequestStateChange (strophe.js:5559)

Is it possibly a configuration parameter to lib-jitsi-meet or strophe itself that is required?


Try to move consider_bosh_secure = true out of the virtual host, add it to the general prosody config in /etc/prosody/prosody.cfg.lua.


@damencho, Still no dice :cry:

The consider_bosh_secure = true flag seems to be only used in mod_bosh.lua.

In Prosody’s source:

# git grep consider_bosh_secure
plugins/mod_bosh.lua:local consider_bosh_secure = module:get_option_boolean("consider_bosh_secure");
plugins/mod_bosh.lua:                   log = logger.init("bosh"..sid), secure = consider_bosh_secure or,

I’m assuming you have a working config that is using mod_auth_http_async?

It’s good to know this is at least possible.

Maybe there is some other magic flag, or configuration that is related to why it works for you…


I think what needs to happen is PLAIN needs to show up in the mechanisms list, but for some reason it is being filtered out.

And according to: it looks like this is removed over ‘unsecure’ connections.

Which, I guess makes sense why consider_bosh_secure should fix it… I wonder if it’s something to do with the version of prosody I am using why it doesn’t appear to respect this flag with regards to the above.

Maybe I should instead use allow_unencrypted_plain_auth = true?


Probably not the best solution, but allow_unencrypted_plain_auth = true works!

At least this confirms my suspicion about the allowed mechanisms.

Now I’m getting:

Logger.js:125 [modules/UI/authentication/AuthHandler.js] <>:  authenticateAndUpgradeRole failed 
{authenticationError: "not-authorized", message: "not authorized user domain"}
"not authorized user domain"

But it’s probably some other misconfiguration.

Thanks for your help @damencho