Connection failure - Access-Control-Allow-Origin

[SuNounix]

Describe the bug

Can't connect to my XMPP server

Connection failure
Une erreur est survenue lors de la connexion au serveur de discussion.

Firefox console :

Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://maindomain.tld/.well-known/host-meta. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant. Code d’état : 302.

Context

• Hardware: VPS
• YunoHost version: 11.1.5.5
• Converse.js version: 10.1.0~ynh1

Steps to reproduce

Just install Converse on a domain other than the primary domain.

[jmthackett]

I'm seeing the same problem:

"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://zzz.zzz/.well-known/host-meta. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 404."

[jmthackett]

Thinking a bit more about this, is there a helper for the main TLD? That would solve this pretty quickly if TOPDOMAIN or similar was a thing. (I still need to read the packaging v2 guide so apologies if that syntax is deprecated..!)

[ericgaspar]

Let me now if #27 fixes the issue.

[jmthackett]

I've looked at #27 and it didn't fix the issue entirely: it does now seem to hit another error. I had a play it seems like the Host header is causing some kind of issue.

This is what is in my - working - nginx config:

    location = /http-bind {
        proxy_pass "http://localhost:5290/http-bind";
        proxy_http_version 1.1;
#        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        tcp_nodelay on;
    }



location / {


    more_set_headers "Access-Control-Allow-Origin: *";
    # Path to source
    alias /var/www/converse/;

    index index.html;

    # Include SSOWAT user panel.
    include conf.d/yunohost_panel.conf.inc;
}

I've switched the /http-bind stanza to be on its own, and ordered it above the / stanza - if memory serves this matters but I've not had time to tidy it up.

Looking at the config for metronome (I assume much the same applies to prosody) it appears that http isn't set up for all hosts:

------ Components ------
-- You can specify components to add hosts that provide special services,
-- like multi-user conferences, and transports.

---Set up a local BOSH service
Component "localhost" "http"
        modules_enabled = { "bosh" }

The config in the docs for metronome specifies either a wildcard or a url:

   Host "*"
       interfaces = { "127.0.0.1", "::1" }
       ssl = { key = "/etc/metronome/certs/localhost.key", certificate = "/etc/metronome/certs/localhost.cert" }
       http_ports = {}
       https_ports = { 443 }

    Component "upload.mydomain.tld" "http_upload"
       http_file_quota = 120*1024*1024 -- File quota per user
       http_file_expire_after = 86400 -- Time to expire files

I'm guessing that when we set the Host header, metronome receives a domain it has no config for and so does nothing useful. I'm reasonably sure not setting the header is harmless enough, and if there is fail2ban setup the X-Forwarded-For or X-Real-IP fields will be enough for it to go on, although I haven't checked.

In any case, I think this is either a) solved or b) a separate bug to the one originally described in this ticket. Happy to hear your thoughts.