How to password protect staging environment?

[Terrapop]

As Discourse is not using Apache how to password protect e.g. a staging environment (Digital Ocean droplet with Discourse docker) as you would do with .htaccess (Apache)?

[david (David Taylor)]

There is no apache, but NGINX is running inside the Discourse container. This topic may help:

Persistent nginx/discourse.conf?

If anyone else is looking to add auth_basic to their site during development, and make it persistent across ./launcher rebuild app just update your containers/app.yml with: ## Any custom commands to run after building run: - exec: echo "Beginning of custom commands" - replace: filename: "/etc/nginx/conf.d/discourse.conf" from: "# auth_basic on" to: "auth_basic on" - replace: filename: "/etc/nginx/conf.d/discourse.conf" from: "# auth_basic_user_file /etc/nginx/htpa…

[Terrapop]

Perfect, thanks @david

[Terrapop]

Just added it but now every picture from https://cdn-uploads.example.com and https://cdn-origin.example.com requires to enter the auth password. Is there a way to only protect https://discourse.example.com?

Otherwise I get this now:

[david (David Taylor)]

I’m not sure exactly how to achieve that, but maybe someone else will jump in if they have some ideas. It should be possible with some tweaks to the nginx config.

As a workaround, and since this is a staging server, could you just disable the CDN? If you use the same domain for assets, they will automatically be sent the authentication header so you won’t need to enter the auth password again.

[Terrapop]

Yes sure, if that is the recommended approach for a staging environment if you use S3 buckets for backups and uploads as well as CloudFront as CDN for uploads and origin on production.

No need to really have all of that for a staging environment?

[david (David Taylor)]

@Terrapop

if you use S3 buckets for backups and uploads as well as CloudFront as CDN for uploads

This nginx change certainly shouldn’t affect S3 uploads or the S3 CDN. NGINX is not involved there at all. I had assumed you were using local uploads with a CDN?

@Terrapop

if that is the recommended approach for a staging environment

The ideal situation is to make the staging site configured identically to the production site.

[Terrapop]

  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

And the main domain for staging is currently https://staging.example.com

Still, I am auth prompted for every single request from cnd-origin with the proposed code when accessing https://staging.example.com

[Terrapop]

Update for those running into the same issue:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesWhitelistHeaders

We had to whitelist the Authorization headers in Cloudfront for cdn-origin.

It’s seem I was not prompted for auth for cdn-uploads.

Works now.

[pfaffman (Jay Pfaffman)]

I turn on login required on the staging site. You can do it with an environment variable in the app.yml so that it’s persistent.

[Terrapop]

No good enough if Google or anybody else is finding the site. Anyways works now.

[pfaffman (Jay Pfaffman)]

They’ll see the site but not be able to see any content. Right?

[Terrapop]

In our case, we have to be able to see how the site reacts to anonymous users as well. So fair enough, works now with basic_auth.

[pfaffman (Jay Pfaffman)]

Well, you have me rethinking how I do this!

[neounix (Dark Matter)]

@Terrapop

As Discourse is not using Apache how to password protect e.g. a staging environment (Digital Ocean droplet with Discourse docker) as you would do with .htaccess (Apache)?

Hey @Terrapop

Here is an idea for you and is how we do it.

If you run your staging env behind Apache2 (or nginx) as a reverse proxy you can set up access rules in the reverse proxy as you would with .htaccess like you are familiar with.

There are myriad advantages for running Discourse behind a reverse proxy and ease of access control is just one benefit.

HTH

[Terrapop]

Is there a fool proof how-to guide for nginix? We’re hosting on Digitalocean via Droplet and Docker.

[neounix (Dark Matter)]

Hi @Terrapop

There are plenty of great tutorials on meta on how to setup Discourse in a “two container” configuration behind a reverse proxy.

You can try searching on meta:

two container  reverse proxy

Hope this helps.

Please note for simply staging, many people do not set up “two containers” and only do this in production; but if you want to stage “exact as in production” then “two containers” is certainly a great way to go. However, you do not need “two containers” to run a web app behind a reverse proxy. I regularly run ROR and Docker web apps behind a reverse proxy in both production and development.

[trying2survive (John)]

Hello. Just want to know how you properly whitelisted the authorization headers in CloudFront? Added “auth_basic” in app.yml as given above. Password-protect is working when browsing via desktop but getting this when browsing via mobile (after entering user and password):

I have this in my “cdn-origin”:

“whitelist-authorization-headers” policy:

Fairly new to CloudFront and I might just be missing something very obvious (for mobile configuration).