J’ai ça aussi : proxy_redirect off;
Oui, le fichier par défaut, donc.
non
oui le fichier par défaut après une purge et une réinstalle complète
c’est vraiment ce souci : Trilium & NGINX Proxy Manager · TriliumNext · Discussion #3531 · GitHub
log navigateur : Refused to apply style from ‘https://xxxx/trilium/assets/v0.99.3/stylesheets/print.css’ because its MIME type (‘application/json’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.
Aucune erreur wss:// ?
Utilises-tu un proxy ?
Connecting to ‘’ violates the following Content Security Policy directive: “default-src https: data: blob:”. Note that ‘connect-src’ was not explicitly set, so ‘default-src’ is used as a fallback. The action has been blocked
par défaut avec yunohost
Le site que tu as masqué est le site où tu as installé trilium ?
oui
Si tu as un doute sur une éventuelle modification de la conf nginx de ce domaine, j’essaierais à ta place d’installer trilium sur un autre domaine ou sur un domaine local pour voir si le même pb se pose.
J’ai manipulé en m’aidant de l’IA sur les logs du navigateur et la solution réside là :
sudo nano /etc/nginx/conf.d/security.conf.inc
remplacé more_set_headers "Content-Security-Policy par
more_set_headers “Content-Security-Policy: upgrade-insecure-requests; default-src https: data: blob:; connect-src ‘self’ https: wss:; object-src https: data: ‘unsafe-inline’; style-src https: data: ‘unsafe-inline’; script-src https: data: ‘unsafe-inline’ ‘unsafe-eval’; worker-src ‘self’ blob:;”;
ajout de : connect-src ‘self’ https: wss:;
Un souci de headers… mais est-ce bien sécure tout ça ?
Ben, en CSP il y a dans une install standard more_set_headers "Content-Security-Policy : upgrade-insecure-requests"; et on ne touche pas à ce fichier normalement 
bah il dit de créer un fichier headers : add_header Content-Security-Policy “default-src https: data: blob:; connect-src ‘self’ https: wss:; img-src https: data:; font-src https: data:; style-src ‘self’ ‘unsafe-inline’ https:; script-src ‘self’ https:;” always;
Puis de toucher à la CSP
Ton fichier headers est lu (on le voit dans la sortie :
headers:add_header Content-Security-Policy …).
Mais il ne remplace pas la politique CSP qui bloque les WebSockets, car une autre directive CSP est encore active ailleurs, et c’est cette autre directive qui s’applique.
Le fichier qui impose la mauvaise CSP est :
/etc/nginx/conf.d/security.conf.inc
Et ce fichier est inclus avant les confs de domaines et s’applique à tous les domaines.
Surtout : il utilise more_set_headers, qui écrase les add_header définis ensuite dans les confs des domaines.
C’est exactement pour ça que ta directive personnalisée n’est pas prise en compte.
Solution propre — modifier la CSP globale de YunoHost pour autoriser Trilium
Tu dois ajouter connect-src 'self' https: wss: directement dans :
/etc/nginx/conf.d/security.conf.inc
Je te confirme ne pas rencontrer d’erreur websocket avec une fresh install de trilium et le fichier /etc/nginx/conf.d/security.conf.inc non modifié.
ça fait le job certes mais j’ai l’impression que c’est pas propre contrairement à ce qu’il essaie de me faire croire…
ok… bizarre donc c’est ma conf
Je ne suis pas en 12.1.36 mais ça m’étonnerait que ça vienne de là.
a la prochaine maj ça va me foutre le chantier ça ?