Comme Discourse n’utilise pas Apache, comment protéger par mot de passe, par exemple, un environnement de staging (un droplet Digital Ocean avec Discourse Docker) comme on le ferait avec .htaccess (Apache) ?
Il n’y a pas d’Apache, mais NGINX s’exécute à l’intérieur du conteneur Discourse. Ce sujet pourrait vous aider :
3 « J'aime »
Parfait, merci @david 
1 « J'aime »
Je viens de l’ajouter, mais désormais, chaque image provenant de https://cdn-uploads.example.com et https://cdn-origin.example.com nécessite de saisir le mot de passe d’authentification. Existe-t-il un moyen de protéger uniquement https://discourse.example.com ?
Sinon, je reçois maintenant ceci :
Je ne suis pas exactement sûr de la manière de réaliser cela, mais peut-être que quelqu’un d’autre interviendra s’il a des idées. Cela devrait être possible avec quelques ajustements dans la configuration nginx.
En solution de contournement, et puisque c’est un serveur de staging, pourriez-vous simplement désactiver le CDN ? Si vous utilisez le même domaine pour les assets, l’en-tête d’authentification leur sera automatiquement envoyé, vous n’aurez donc pas besoin de saisir à nouveau le mot de passe d’authentification.
1 « J'aime »
Oui, bien sûr, si c’est l’approche recommandée pour un environnement de staging, notamment si vous utilisez des buckets S3 pour les sauvegardes et les uploads, ainsi que CloudFront en tant que CDN pour les uploads et l’origine en production.
Pas vraiment besoin de tout cela pour un environnement de staging ?
Ce changement dans nginx ne devrait certainement pas affecter les téléchargements S3 ni le CDN S3. NGINX n’est pas impliqué là-dedans du tout. J’avais supposé que vous utilisiez des téléchargements locaux avec un CDN ?
La situation idéale consiste à configurer le site de staging de manière identique au site de production.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
Le domaine principal pour la mise en scène est actuellement https://staging.example.com
Cependant, je suis toujours invité à m’authentifier pour chaque requête provenant de cdn-origin avec le code proposé lors de l’accès à https://staging.example.com
Mise à jour pour ceux qui rencontrent le même problème :
Nous avons dû autoriser les en-têtes Authorization dans CloudFront pour cdn-origin.
Il semble que je n’aie pas été invité à fournir une authentification pour cdn-uploads.
Cela fonctionne maintenant.
2 « J'aime »
J’ai activé l’authentification requise sur le site de préproduction. Vous pouvez le faire via une variable d’environnement dans app.yml pour que cela soit persistant.
Pas assez bien si Google ou quiconque d’autre trouve le site. Quoi qu’il en soit, ça fonctionne maintenant.
1 « J'aime »
Ils verront le site mais ne pourront pas voir le contenu. C’est bien ça ?
Dans notre cas, nous devons également pouvoir voir comment le site réagit aux utilisateurs anonymes. Donc, c’est logique, cela fonctionne maintenant avec basic_auth.
2 « J'aime »
Eh bien, tu me fais reconsidérer ma façon de faire !
Salut @Terrapop,
Voici une idée pour toi, et c’est ainsi que nous procédons.
Si vous exécutez votre environnement de staging derrière Apache2 (ou nginx) en tant que proxy inverse, vous pouvez configurer des règles d’accès dans le proxy inverse comme vous le feriez avec .htaccess, comme vous en avez l’habitude.
Il existe une multitude d’avantages à exécuter Discourse derrière un proxy inverse, et la facilité de contrôle d’accès n’est qu’un des bénéfices.
J’espère que cela vous aide.
Existe-t-il un guide infaillible pour Nginx ? Nous hébergeons sur DigitalOcean via un Droplet et Docker.
Bonjour @Terrapop,
Il existe de nombreux excellents tutoriels sur Meta concernant la configuration de Discourse en mode « deux conteneurs » derrière un proxy inverse.
Vous pouvez essayer de rechercher sur Meta :
two container reverse proxy
J’espère que cela vous aidera.
Veuillez noter que pour une simple mise en scène (staging), beaucoup de personnes ne configurent pas de « deux conteneurs » et ne le font qu’en production ; mais si vous souhaitez simuler « exactement comme en production », alors les « deux conteneurs » sont certainement une excellente option. Cependant, vous n’avez pas besoin de « deux conteneurs » pour exécuter une application web derrière un proxy inverse. J’exécute régulièrement des applications web ROR et Docker derrière un proxy inverse, tant en production qu’en développement.
3 « J'aime »
Bonjour. Je voudrais simplement savoir comment vous avez correctement autorisé les en-têtes d’authentification dans CloudFront ? J’ai ajouté “auth_basic” dans app.yml comme indiqué ci-dessus. La protection par mot de passe fonctionne lorsque je navigue depuis un ordinateur de bureau, mais j’obtiens ceci lorsque je navigue depuis un mobile (après avoir saisi l’identifiant et le mot de passe) :
J’ai ceci dans mon “cdn-origin” :
Stratégie “whitelist-authorization-headers” :
Je suis assez nouveau sur CloudFront et il se peut que j’aie simplement oublié quelque chose d’évident (pour la configuration mobile).