nginx/discourse.conf ثابت؟

When I’m using the current default docker install of discourse, ./launcher enter app the container, /etc/nginx/conf.d/discourse.conf contains:

  location / {
    root $public;
    add_header ETag "";

    # auth_basic on;
    # auth_basic_user_file /etc/nginx/htpasswd;

    location ~* (assets|plugins|uploads)/.*\.(eot|ttf|woff|woff2|ico)$ {

I would like to enable auth_basic while working on my site, but I frequently end up doing ./launcher rebuild app as there’s inevitably something else to reconfigure or something to change.

Unfortunately, each time this wipes out my basic auth, making my completely private site public. (other people looking at the site are especially interested in how registration for new users will work… so basic auth seems to be the best solution).

I’ve noticed that most of the “customizing nginx” discussion on meta talks about setting up a completely separate nginx instance, which certainly seems like overkill here considering what I want is already in the file, just commented out.

So what’s the right procedure so that my basic auth will survive reboots? Do I make my own pups template in /templates, or use write it at the bottom of my /containers/app.yml in the final ## Any custom commands to run after building run: section?

إعجاب واحد (1)

Better choice can be to run your container behind an nginx reverse proxy to handle the auth_basic

3 إعجابات

An alternative is to use pups directives in your app.yml to have the modifications you need applied during rebuild :slight_smile:

5 إعجابات

@fefrei thank you for your suggestion and for reading clearly :smile:

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/htpasswd"
     to: "auth_basic_user_file /etc/nginx/htpasswd"
  - file:
     path: "/etc/nginx/htpasswd"
     contents: |
      myuser:$apr1$pVrNvrxt$QvutzMrHfb2IYDNUOk54o0
     # use: `openssl passwd -apr1` to generate password hash

Of course update myuser to be the actual username you want and run openssl passwd -apr1 to generate a hash of your real password.

Or you could install a whole separate instance of nginx and create a reverse proxy just for this… Whichever is easier for you :wink:

9 إعجابات

شكرًا لك، @ryanerwin! كان هذا عونًا كبيرًا. إذا كنت تعتمد على /srv/status ليعمل لسبب ما، فإن حلّك يكسره. إليك كيفية السماح بخدمة /srv/status دون استخدام auth_basic.

# المصادقة الأساسية
    - استبدال:
       الملف: "/etc/nginx/conf.d/discourse.conf"
       من: "# auth_basic on"
       إلى: "auth_basic on"
    - استبدال:
       الملف: "/etc/nginx/conf.d/discourse.conf"
       من: "# auth_basic_user_file /etc/nginx/htpasswd"
       إلى: "auth_basic_user_file /etc/nginx/htpasswd"
    - استبدال:
       الملف: "/etc/nginx/conf.d/discourse.conf"
       من: "location = /srv/status {"
       إلى: "location = /srv/status {
           auth_basic off;"
    - ملف:
       المسار: "/etc/nginx/htpasswd"
       المحتويات: |
        discourse:$apr1$y2JsCAxw$UuDgGdsoXNf.4Rl15Hp2b0

المثال أعلاه للمستخدم “discourse” وكلمة المرور “password”، ورغم أن ذلك ممارسة غير جيدة، إلا أننا نريد فقط التأكد من الحصول على كلمة مرور لا يستطيع الزائر الآلي تخمينها.

يمكنك أيضًا توليد كلمة مرور على النحو التالي:

htpasswd -cb password_file user password
cat password_file
إعجابَين (2)