بما أن Discourse لا يستخدم Apache، فكيف يمكن حماية بيئة تجريبية (مثل Droplet من Digital Ocean يشغل Discourse عبر Docker) بكلمة مرور، كما هو الحال مع .htaccess في Apache؟
لا يوجد Apache، ولكن يعمل NGINX داخل حاوية Discourse. قد يساعدك هذا الموضوع:
ممتاز، شكرًا لك @david ![]()
لقد أضفتها للتو، لكن الآن كل صورة من https://cdn-uploads.example.com و https://cdn-origin.example.com تتطلب إدخال كلمة مرور المصادقة. هل هناك طريقة لحماية https://discourse.example.com فقط؟
وإلا فسأحصل على هذا الآن:
لست متأكدًا تمامًا من كيفية تحقيق ذلك، لكن ربما يتدخل شخص آخر إذا كانت لديه بعض الأفكار. يجب أن يكون ذلك ممكنًا مع بعض التعديلات في تكوين nginx.
كحل بديل، وبما أن هذا خادم مرحلي، هل يمكنك ببساطة تعطيل CDN؟ إذا استخدمت نفس النطاق للأصول، فسيتم إرسال رأس المصادقة إليها تلقائيًا، لذا لن تحتاج إلى إدخال كلمة مرور المصادقة مرة أخرى.
نعم، بالتأكيد، إذا كانت هذه هي الطريقة الموصى بها لبيئة الاختبار (staging) عند استخدام صناديق S3 للنسخ الاحتياطي والتحميلات، بالإضافة إلى CloudFront كشبكة توصيل محتوى (CDN) للتحميلات ونقطة المنشأ في بيئة الإنتاج.
لا داعي حقًا لتوفر كل ذلك في بيئة الاختبار؟
بالتأكيد، لا ينبغي أن يؤثر هذا التغيير في nginx على رفع الملفات إلى S3 أو على شبكة توصيل المحتوى (CDN) الخاصة بـ S3. فـ NGINX لا يتدخل في ذلك على الإطلاق. لقد افترضت أنك كنت تستخدم رفع الملفات محليًا مع شبكة توصيل محتوى (CDN)؟
الوضع المثالي هو جعل موقع الاختبار مُهيأً بنفس طريقة موقع الإنتاج.
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
وحاليًا، يكون النطاق الرئيسي لبيئة الاختبار هو https://staging.example.com
ومع ذلك، لا يزال يتم مطالبتني بالمصادقة في كل طلب فردي من cnd-origin عند الوصول إلى https://staging.example.com باستخدام الكود المقترح.
تحديث لمن يواجهون نفس المشكلة:
كان علينا السماح بعناوين Authorization في Cloudfront لـ cdn-origin.
يبدو أنني لم أُطلب المصادقة لـ cdn-uploads.
يعمل الآن.
لقد قمت بتفعيل خيار “تسجيل الدخول مطلوب” على موقع الاختبار (staging). يمكنك فعل ذلك عبر متغير بيئة في ملف app.yml لضمان استمرار الإعداد.
ليس جيدًا بما يكفي إذا كان جوجل أو أي شخص آخر يجد الموقع. على أي حال، يعمل الآن.
سيرون الموقع لكن لن يتمكنوا من رؤية أي محتوى. صحيح؟
في حالتنا، يجب أن نتمكن من رؤية كيفية تفاعل الموقع مع المستخدمين المجهولين أيضًا. إذن، هذا معقول، ويعمل الآن مع basic_auth.
حسناً، لقد جعلتني أعيد التفكير في طريقة عملي!
مرحبًا @Terrapop
إليك فكرة نطبقها نحن:
إذا قمت بتشغيل بيئة الاختبار الخاصة بك خلف خادم وكيل عكسي مثل Apache2 أو nginx، فيمكنك إعداد قواعد الوصول في الوكيل العكسي بنفس الطريقة التي تتعامل بها مع ملف .htaccess المألوف لديك.
هناك فوائد عديدة لتشغيل Discourse خلف وكيل عكسي، وسهولة التحكم في الوصول هي مجرد واحدة منها.
أتمنى أن يكون ذلك مفيدًا.
هل توجد دليل خطوة بخطوة لا يُخطئ في nginx؟ نحن نستضيف على DigitalOcean عبر Droplet و Docker.
مرحبًا @Terrapop
هناك العديد من الدروس الممتازة على موقع Meta حول إعداد Discourse في تكوين “حاويتين” خلف وكيل عكسي.
يمكنك محاولة البحث على Meta:
two container reverse proxy
آمل أن يكون هذا مفيدًا.
يرجى ملاحظة أنه بالنسبة للمراحل التجريبية البسيطة، لا يقوم العديد من الأشخاص بإعداد “حاويتين” ويفعلون ذلك فقط في بيئة الإنتاج؛ ولكن إذا كنت ترغب في محاكاة البيئة “تمامًا كما هي في الإنتاج”، فإن استخدام “حاويتين” هو بالتأكيد خيار ممتاز. ومع ذلك، لا تحتاج إلى “حاويتين” لتشغيل تطبيق ويب خلف وكيل عكسي. فأنا أقوم بانتظام بتشغيل تطبيقات ROR و Docker خلف وكيل عكسي في كل من بيئتي الإنتاج والتطوير.
مرحبًا. أود فقط معرفة كيفية إضافة رؤوس التفويض إلى القائمة البيضاء بشكل صحيح في CloudFront؟ أضفت “auth_basic” في ملف app.yml كما هو موضح أعلاه. يعمل حماية بكلمة المرور عند التصفح عبر سطح المكتب، لكنني أحصل على هذا عند التصفح عبر الهاتف المحمول (بعد إدخال اسم المستخدم وكلمة المرور):
لدي هذا في “cdn-origin”:
سياسة “whitelist-authorization-headers”:
أنا جديد نسبيًا في CloudFront وقد يكون الأمر مجرد شيء واضح جدًا (لإعداد الهاتف المحمول) قد فاتني.




