• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Question Proxy/Secured HTTP & WS requests to avoid CORS

Lrnt

Basic Pleskian
Server operating system version
Debian 12.7
Plesk version and microupdate number
Plesk Obsidian 18.0.64 Mise à jour n° 1 Web Pro Edition
Hello!

I have a "webapp" (basically a mini site) running with PHP/mySQL and JavaScript on my Plesk Obsidian 18.0.64 server with Debian 12.7.

This webapp runs on an Android tablet in different "rooms" and allows users to place drink orders and, more importantly, control a sound console and a lighting console.

The sound console is a Soundcraft Ui12, which has an unsecured websocket that allows making WS calls: ws://[soundcraft_local_ip]/[command].

The lighting console is a Cuety LPU-2, which can receive HTTP calls to trigger actions: http://[cuety_local_ip]/action.

Basically, you push a button on webapp it send a request to the device and the lights change or sound volume increase.

As a result, I have to run my webapp in unsecured HTTP to avoid CORS issues during these calls.

This is becoming a major issue as browsers are increasingly secure, and the manufacturers of my devices won't modify their systems to be secured.

I would like to run my webapp on HTTPS, but this is incompatible with the HTTP of the Cuety and the WS of the Soundcraft.

Is there a relatively simple way to transform (or make it seem like) my requests to these devices are "secured," so I no longer have CORS problems?

Maybe through an Nginx proxy or directives on the domain (without modifying the general server configuration), a subdomain, or something else?

The goal would be for me to make HTTPS and WSS requests, but in reality, they would call HTTP and WS.

I hope you understand my problem. Of course, I can provide more details.

Thank you very much for your help.
 
Since these are the only directives that Plesk accepts...
Do you think this can work?

# Soundcraft directives (Eg. wss://192.168.0.12/playback -> ws://192.168.0.12/playback)

NGINX:
location /soundcraft/ {
        # Extrait l'adresse IP ou le nom d'hôte après /soundcraft/
        rewrite ^/soundcraft/(.*)$ /$1 break;  # Récupère l'IP

        # Redirige vers l'adresse IP en WS
        proxy_pass ws://$1;  # Redirige vers l'adresse IP en WS

        # En-têtes pour préserver les informations du client
        proxy_http_version 1.1;  # Nécessaire pour WebSocket
        proxy_set_header Upgrade $http_upgrade;  # Nécessaire pour le passage de WebSocket
        proxy_set_header Connection "Upgrade";  # Nécessaire pour le passage de WebSocket
        proxy_set_header Host $host;  # Préserve le nom d'hôte
        proxy_set_header X-Real-IP $remote_addr;  # IP réelle du client
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # Préserve les IPs
        proxy_set_header X-Forwarded-Proto $scheme;  # Préserve le schéma (http/https)
    }

# Cuety directives (Eg. https://www.domain.tld/cuety/192.168.0.15/pb10/go -> http://192.168.0.15/pb10/go)

NGINX:
location /cuety/ {
    # Réécrit l'URL pour passer à l'adresse IP en HTTP
    rewrite ^/cuety/(.*)$ http://$1 break;

    # Redirige vers l'adresse IP en HTTP
    proxy_pass http://$1;

    # En-têtes pour préserver les informations du client
    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;

    # Pour éviter les problèmes de CORS
    add_header 'Access-Control-Allow-Origin' '*' always;  # Autoriser toutes les origines
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;  # Méthodes autorisées
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;  # En-têtes autorisés

    # Gérer les requêtes OPTIONS pour le CORS
    if ($request_method = OPTIONS) {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
        return 204;  # Pas de contenu pour la requête OPTIONS
    }
}
 
Back
Top