Accès externe : problème avec Content Security Policy

Bonjour à tous,

[EDIT] voir quelques posts plus bas, le problème est plus global :wink:

J’utilise l’application Companion (à jour), et je n’arrive pas à avoir les fond de carte :

Je précise que cela se produit uniquement lorsque je ne suis pas chez moi. Une fois connecté à mon wifi tout est ok (j’ai testé à différents endroits, 4G , 5G, wifi du taf, toujours pas de cartes…)

Mon téléphone est un Pixel 7 Pro, sans VPN ni rien qui pourrait bloquer ces fonds de carte (sauf si quelque chose m’échappe)…

Est-ce que quelqu’un aurait une idée ?
Sur PC tout s’affiche très bien

Merci d’avance

Ça dit quoi si tu navigues sur le site openstreetmap avec ton téléphone ?

Salut

Aucun problème la carte s’affiche correctement sur le site open street map:

Bonjour à tous,

en fait je viens de comprendre que ce n’est pas lié à mon téléphone ni à l’application compagnon, car en lançant sur PC avec l’URL extérieure, je n’ai pas de fond de carte non plus.

Donc un petit tour dans le debugger du navigateur et là :

Les tuiles ne sont pas chargées.

image

Mais je me rend compte que j’ai un soucis bien plus global :frowning:

Si jamais un professionnel des CSP passe par ici :wink:

Salut

Pas forcément besoin d’un expert forcément.
https://clients.offshore-cloud.com/knowledgebase/75/Difference-entre-les-en-tetes-de-securite-CORS-et-CSP.html

En gros tu mélanges des images issues d’une url différente de ton domaine… Par principe, ça ne fonctionne pas, car pas une bonne pratique sécurité.

Et comme tu n’as pas indiqué comment tu rends l’accès extérieur possible, ni la version/ le type HA de ton installation, ni ce que tu utilises pour te positionner (avec openstreetmap) … ben il y a pas de réponse universelle

Salut @eZaz

Sans les infos manquantes signalées par @Pulpy-Luke, ce sera difficile de t’aider efficacement.

En attendant, et en admettant que tu puisses modifier les CSP il faudrait passer de

"worker-src blob:"

à

"worker-src blob: https://basemaps.cartocdn.com/"

Mais comme il nous manque des infos, c’est sans garantie sur les potentiels impacts :confused:

Merci pour vos réponses

Concernant les informations manquantes :

  • Container docker HA (2023.02) sur un raspberry PI 4 (debian 10).

  • Accès extérieur : sous-domaine Free ( xxx.freeboxos.fr).
    J’ai ouvert un port particulier sur ma freebox et j’ai fait une rédirection dans apache pour HTTP et WebSocket vers HA.
    Tout cela avec un certificat lets encrypt.

J’ai ouvert ce sujet car au départ j’avais un soucis de fond de carte, mais je me rend compte que le sujet est plus vaste.
Par exemple depuis l’extérieur, je n’ai pas accès à la liste de mes appareils, automations, etc.

Je vois beaucoup d’erreurs liées au worker dans le débugger :

J’avoue que ça dépasse mes compétences…

C’est toi qui a créé les vhost apache ?

Sur une de tes captures on voit :

image

Alors le *.jeedom.com soit tu l’as ajouté, soit quelqu’un l’a fait pour toi.

Bref je suis plus nginx que apache, mais si tu sais partager tes vhosts et ta conf apache, peut-être qu’on pourra t’aider.

J’ai l’impression que c’est un HA en mode docker + jeedom dans une même VM…

Ce serait original :flushed:

Oui c’est tout à fait ça.

En fait, j’étais sous jeedom depuis quelques années sur ce RPI4, et j’ai voulu tester HA.
La solution du container était la adaptée pour ça.

Maintenant que je suis convaincu, je fais ma migration vers HA, puis je passerai sur l’OS de HA quand tout sera terminé :wink:

Concernant les vhost, les vhost « defaults » ont été écrit par jeedom, puis surchargés par lets encrypt lorsque j’ai installé le certificat SSL mais le vhost pour HA a été écrit par moi en revanche :

<IfModule mod_ssl.c>
<VirtualHost *:10444>
        ServerName xxxx.freeboxos.fr
        SSLCertificateFile /etc/letsencrypt/live/xxx.freeboxos.fr/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/xxx.freeboxos.fr/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf

        RewriteEngine on

        ProxyPreserveHost On
        ProxyRequests off
        ProxyPass /api/websocket ws://localhost:8123/api/websocket
        ProxyPassReverse /api/websocket ws://localhost:8123/api/websocket

        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /(.*)  ws://localhost:8123/$1 [P,L]
        RewriteCond %{HTTP:Upgrade} !=websocket [NC]
        RewriteRule /(.*)  http://localhost:8123/$1 [P,L]

</VirtualHost>
</IfModule>

Je découvre le *.jeedom.com, je n’avais pas remarqué !
Je ne comprends pas ce que ça fait là :confused:

c’est un point de vue qui se défend, mais mélanger HA et jeedom sur une vieille version de debian, c’est pas forcement optimal quand même.
Et ça va plus loin que ça parce que tu mutualise aussi le serveur WEB : apache de jeedom fait plus ou moins proxy pour HA. En ayant la main que partiellement sur la config (jeedom n’a pas pour habitude d’être partageur dans la gestion des droits) c’est encore plus risqué à mon sens.

Ben non, cf la remarque au dessus… C’est un coup de bol que HA n’ai rien pété en ajoutant les certificats et encore plus que jeedom n’ai pas tout remplacé par un truc à lui sans se poser de question.
Et comme la partie CORS est définie par jeedom, ben tu as ce beau message d’alerte

Perso, je vois 2 solutions:

  • simple : laisser comme ça vivre avec l’erreur des cartes jusqu’à la fin de migration
  • compliqué : monter une belle infra (chacun sa chambre), séparer les applications, mettre un proxy à la main en amont … C’est pas le délai, coup, risque

Merci pour ta réponse

Pour moi utiliser Apache pour faire proxy ne posait pas de problème sachant que j’utilisais un port bien séparé et je pensais bien rediriger mais tu as raison, chacun sa chambre serait une bien meilleure solution !

Je pense donc opter pour la solution de terminer sagement la migration puis installer un OS propre plus tard. Car j’ai encore beaucoup de choses à apprendre sur les serveurs web visiblement ! De plus, en local pas de problème tout fonctionne bien.

De ce que j’ai lu, passer du container à l’OS ça se fait bien.

Merci en tout cas pour vos lumières