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
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à :
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
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.
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é
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 :
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
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.