J’aimerais tester Discourse sans nécessairement passer par son nom de domaine public configuré. Par exemple, si Discourse a été installé et configuré comme https://uat.mysite.com, je peux évidemment ouvrir mon navigateur et accéder à https://uat.mysite.com, ce qui signifie que mon navigateur quittera mon réseau interne pour accéder à Internet afin de résoudre le nom de domaine vers son adresse IP publique, et charger les pages via son adresse IP publique.
J’ai essayé d’accéder à Discourse via l’adresse IP interne du serveur (par exemple, 192.168.1.2, montré ci-dessous) et, à juste titre, cela ne se charge pas en raison de la politique de sécurité du contenu (Content Security Policy). Les erreurs que je reçois sont de la forme suivante.
Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
La raison pour laquelle je souhaite accéder à Discourse via l’adresse IP interne du serveur est que je veux faire des tests. Par exemple, si je veux effectuer des tests de chargement, je ne veux pas nécessairement utiliser le réseau qui dessert Internet. Ou si je veux installer une instance de test sur mon ordinateur portable ou un serveur de build sans avoir à configurer DNS.
Je suppose que je peux toujours outrepasser cela en définissant une entrée personnalisée dans /etc/hosts, mais existe-t-il un moyen de désactiver CSP ou de le configurer pour faire confiance à d’autres sources afin de permettre les tests ?
Configurez ensuite votre machine pour résoudre cette adresse en l’adresse IP locale du serveur Discourse. Il existe de nombreuses façons de le faire, mais elles dépendent du système d’exploitation, vous devriez donc inclure le système d’exploitation dans votre recherche Google. (Sous Linux et je pense que Mac le fait aussi, vous pouvez simplement modifier /etc/hosts.)
J’ai en fait essayé /etc/hosts mais j’ai toujours la même erreur à cause de CSP. J’aurais pensé qu’il existe un drapeau ou un paramètre qui pourrait être utilisé pour basculer cela afin de permettre aux développeurs de tout faire sur leur ordinateur portable sans avoir à mettre en place une solution DNS. En regardant le Installer Discourse sur macOS pour le développement - documentation / développeurs - Discourse Meta, il semble qu’il démarre quelque chose qui fonctionne avec http://localhost:3000 plutôt qu’une adresse IP.
Le défi que j’ai est que j’ai une automatisation pour installer Discourse et je veux utiliser le même processus pour mettre en place les environnements de développement, UAT et de production, et je ne veux pas nécessairement que l’environnement de développement soit accessible depuis Internet, ce qui semble être une exigence actuelle car il doit résoudre un FQDN approprié. Il existe plusieurs cas d’utilisation, dont l’un consiste, par exemple, à automatiser la mise à niveau de Discourse dans l’environnement de développement chaque semaine et à exécuter un certain nombre de tests pour voir si quelque chose se casse.
Quoi qu’il en soit, s’il existe un moyen d’assouplir l’exigence pour permettre un accès direct via IP, ce serait bien de le savoir. Sinon, je suppose que la seule autre solution est de mettre en place un petit service DNS, puis de configurer l’ordinateur portable pour utiliser le service DNS personnalisé, mais cela semble être un peu compliqué.
Ce n’est pas une bonne idée. Ça ne marchera jamais. Un environnement de développement est nécessairement différent car il a des ressources précompilées et un tas d’autres choses qui rendent le développement impossible. À moins que vous ne développiez des plugins, vous n’avez pas du tout besoin d’un environnement de développement. Donc, si c’est le cas, alors vous pouvez avoir votre environnement de développement comme une installation docker, ce n’est juste pas ce qu’on appellerait un environnement de développement ici.
Vous voulez lancer vos environnements de staging et de production en utilisant docker comme décrit dans l’installation standard.
Salut ! Je fais régulièrement cela, mais avec des installations Docker. En supposant que vous utilisiez notre installation Docker standard en production, alors pour vos tests d’acceptation, vous devriez utiliser la même chose. Il y a une grande marge de différences entre les installations de développement et Docker (configuration, versions des gemmes et des paquets JS, etc.) qui peuvent se transformer en migraines au moment du déploiement.
Les installations Docker utilisent et appliquent le HTTPS par défaut. À moins que vous ne souhaitiez personnaliser le modèle de conteneur (ce que j’ai trouvé avoir une complexité cachée), vous pouvez simplement désactiver l’application du HTTPS avec un autre paramètre de site.
Voici mon extrait pour « assouplir la sécurité dans une installation Docker locale », qui peut tout aussi facilement être annulé avant d’aller en production :
Ensuite, il suffit que votre navigateur puisse trouver le port 80 sur le conteneur Docker à http://uat.mysite.com – notez que vous utiliserez http au lieu de https.
Pour cela, l’astuce de /etc/hosts de @pfaffman est la bonne méthode ; détails pour chaque OS ici.