تم ضبطه في كتلة الإعدادات النموذجية الخاصة بـ Vultr في المنشور الأصلي. انسخ والصق في ملف app.yml الخاص بك، ثم عدّل الحقول اللازمة.
إعجابَين (2)
شكرًا لك، لقد فوّت هذا الجزء:
إعجاب واحد (1)
الأمر لا يسير بسلاسة بالنسبة لي، آسف على الرد عدة مرات.
إذا قمت بما سبق، هل يجب أن أتجاهل إعدادات لوحة التحكم لـ S3 والنسخ الاحتياطي؟
أم أنه يجب أيضًا تكوين إعدادات لوحة التحكم؟
إعجاب واحد (1)
كل ما عليك فعله هو اتباع هذا الدليل الموجود في المنشور الأصلي، وستحصل على تكوين فعال لتخزين الكائنات.
3 إعجابات
تعيين هذه المتغيرات يجعلها غير متاحة من واجهة المستخدم. يجب تعيينها كما هو موضح هنا بدلاً من واجهة المستخدم.
إعجابَين (2)
أعتقد أن الأمر يعمل الآن (في الغالب؟)، لكن هل هذا content security policy script src آمن؟
أستخدم AWS لخادمين S3 (للرفع والنسخ الاحتياطي)، وخادمين CDN من CloudFront (للملفات والأصول). عندما أستخدم أسماء CNAME الخاصة بي لخوادم CloudFront CDN، أواجه العديد من أخطاء الشبكة المتعلقة بـ script-src في المتصفح عند تحميل Discourse. لم تعد هناك أخطاء بعد إضافة هذه الإدخالات إلى سياسة أمن المحتوى (CSP) الخاصة بي.
إعجاب واحد (1)
هل هذه هي عناوين URL التي وضعتها في متغيرات البيئة الموصوفة في المنشور الأصلي؟ وهل هي محمية بـ https؟
إعجاب واحد (1)
نعم، لا تظهر تحذيرات script-src عندما أضع عنواني d23whatever.cloudfront.net في متغيرات البيئة. لكن عندما أضع عناويني المخصصة، أي community-cdn.mydomain و files-cdn.mydomain، في متغيرات البيئة، تظهر هذه التحذيرات. ويبدو أن مكتبة Stripe JS لا تزال تسبب لي هذه التحذيرة رغم أنها مدرجة في content security policy script src.
إعجابَين (2)
لقد قمت بإعداد تحميلات S3 وتخزين الكائنات كما هو موضح هنا في OP، ولكن بدون شبكة توصيل محتوى (CDN).
بالنسبة للمتغير DISCOURSE_S3_CDN_URL، لدي هذا:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
كل شيء يبدو جيدًا، بما في ذلك النسخ الاحتياطي، ومع ذلك، في وحدة التحكم يظهر هذا الخطأ عند بدء الرد على منشور:
عنوان URL للطلب في الخطأ هو في الواقع سلسلة من عنواني URL، مما يبدو أنه السبب؟
https://mydiscourse.com/t/uploads-test-for-s3/79/https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com/assets/markdown-it-bundle-a7328b73d3e7b030770eab70f10bdb0af655b3d8fa929bc49f1ad04c4cdaa198.br.js
إعجابَين (2)
شبكة توصيل المحتوى (CDN) إلزامية لكي تعمل بشكل صحيح.
4 إعجابات
أنا أيضًا في هذا الموقف مع مخزن كائنات مُعد (minio) ولكن بدون شبكة توصيل محتوى (CDN). هل هذه حالة استخدام يمكن دعمها؟
مما أراه حتى الآن في اختباراتي، فإن ملف markdown-it-bundle جافاسكريبت هو الوحيد الذي يواجه مشكلات لأنه يشير إلى عنوان URL خاطئ - DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
يبدو في الواقع وكأنه خطأ في هذا الملف، إذا قمت بتعيين المتغير DISCOURSE_CDN_URL، فإنه لا يزال يشير إلى عنوان URL خاطئ بهذا الشكل DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
يجب أن يشير إلى DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
ملفات جافاسكريبت الأخرى تشير إلى عنوان URL الصحيح.
أعتقد مما تقوله أنني سأواجه مشاكل أخرى لم أكتشفها بعد. ربما يمكنك تزويدي بمزيد من المعلومات حول ما يمكن أن يحدث بشكل خاطئ؟
إذا فهمت بشكل صحيح، فإن ملفات جافاسكريبت موجودة على مخزن الكائنات، ويجب أن تكون أوراق الأنماط على شبكة توصيل محتوى (CDN). بدون شبكة توصيل محتوى (CDN)، هل يمكن تسليم أوراق الأنماط بواسطة التطبيق كالمعتاد؟ (مما أراه هو هذه الحالة)
شكراً لمساعدتك.
3 إعجابات
هذه ليست حالة استخدام مدعومة وفقًا للمنشور الأصلي:
إعجاب واحد (1)
إلى الجميع،
لقد قمت بإعداد خادم Discourse جديد باستخدام Lightsail، مستخدمًا هذا الدليل لتحميلات S3 والنسخ الاحتياطي setting-up-file-and-image-uploads-to-s3
بعد الإعداد، ظهر لي الخطأ المعروض “لا تسمح الحاوية بـ ACLs” على الشاشة عند تحميل صورة
هذه هي سياستي لـ S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersionTagging",
"s3:CreateBucket",
"s3:GetObjectAcl",
"s3:GetBucketObjectLockConfiguration",
"s3:PutLifecycleConfiguration",
"s3:GetObjectVersionAcl",
"s3:PutObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:GetBucketPolicyStatus",
"s3:GetObjectRetention",
"s3:GetBucketWebsite",
"s3:ListJobs",
"s3:DeleteObjectVersionTagging",
"s3:GetObjectLegalHold",
"s3:GetBucketNotification",
"s3:PutBucketCORS",
"s3:GetReplicationConfiguration",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:GetObject",
"s3:DescribeJob",
"s3:PutObjectVersionAcl",
"s3:GetAnalyticsConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetLifecycleConfiguration",
"s3:GetAccessPoint",
"s3:GetInventoryConfiguration",
"s3:GetBucketTagging",
"s3:GetBucketLogging",
"s3:ListBucketVersions",
"s3:ReplicateTags",
"s3:ListBucket",
"s3:GetAccelerateConfiguration",
"s3:GetBucketPolicy",
"s3:GetEncryptionConfiguration",
"s3:GetObjectVersionTorrent",
"s3:AbortMultipartUpload",
"s3:PutBucketTagging",
"s3:GetBucketRequestPayment",
"s3:GetAccessPointPolicyStatus",
"s3:GetObjectTagging",
"s3:GetMetricsConfiguration",
"s3:PutObjectAcl",
"s3:GetBucketPublicAccessBlock",
"s3:ListBucketMultipartUploads",
"s3:ListAccessPoints",
"s3:PutObjectVersionTagging",
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetObjectTorrent",
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetAccessPointPolicy",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::mybucket-upload",
"arn:aws:s3:::mybucket-upload/*",
"arn:aws:s3:::mybucket-backup",
"arn:aws:s3:::mybucket-backup/*"
]
}
]
}
وهذا هو إعداد الوصول العام الخاص بي لحاوية S3:
هل يمكن لأحد مساعدتي في حل هذه المشكلة، من فضلك؟
شكرا جزيلا
تحياتي،
كوانغ
3 إعجابات
هل يجب أن يستخدم موقع الاختبار الخاص بي نفس حاوية S3 مثل موقع الإنتاج الخاص بي؟
إعجاب واحد (1)
لا، سيكون ذلك غير آمن للغاية، ويمكن أن يحذف ملفات يجب أن تظل موجودة في البيئة الأخرى ويغير ملفات من البيئة الأخرى (مما قد يتسبب في فقدان ملفات، أو ملفات خاطئة، وما إلى ذلك).
يجب أن تكون كلتا الحاويتين (buckets) وبيانات الاعتماد مختلفة (ولا يجب أن يكون لبيانات اعتماد المرحلة وصول إلى حاوية الإنتاج، خاصة فيما يتعلق بعمليات الكتابة والحذف).
ربما تكون هناك طريقة لاستخدام مسارات ببيانات اعتماد مختلفة لكل مسار، ولكن احتمالات إلحاق الضرر بنفسك عالية، لذا أنصح باستخدام حاويات منفصلة.
5 إعجابات
هل يجب أن يكون DISCOURSE_CDN_URL و DISCOURSE_S3_CDN_URL منفصلين أيضًا؟
إعجاب واحد (1)
أفترض ذلك، لأنه إذا كانت نطاقات/عناوين URL الخاصة بالمرحلة والإنتاج مختلفة (وهي كذلك، أليس كذلك؟)، فإن DISCOURSE_CDN_URL (التي تشير في النهاية إلى موفر شبكة توصيل المحتوى، والذي يشير إلى نطاق موقعك على الويب) يُتوقع أن تكون مختلفة للمرحلة والإنتاج. وينطبق المنطق نفسه على DISCOURSE_S3_CDN_URL (لأن الدلاء المختلفة يجب أن يكون لها عناوين URL مختلفة).
4 إعجابات
مرحباً بالجميع، أنا جديد جداً على S3، لذلك لست متأكداً تماماً من كيفية صياغة هذا، لكنني سأبذل قصارى جهدي. لقد انتقلت للتو إلى استخدام S3 لعمليات التحميل والنسخ الاحتياطي، وكنت أستخدم Discourse Connect للسماح بتسجيل الدخول في أجزاء أخرى من موقعي، ولكن الآن لم تعد صور الملف الشخصي تعمل. أعتقد أن هذا يتعلق بسياسات CORS، لكنني لست متأكداً من أين يمكنني تكوينها. أفضل أن أقوم بإدراجها في القائمة البيضاء لـ forum.domain.tld و domain.tld - أو يمكن أن يعمل رمز بدل على جميع النطاقات الفرعية أيضاً. هل هذا شيء يمكنني تعيينه في Discourse، أم أين بالضبط؟ أنا أستخدم Vultr object storage إذا كان هذا يحدث فرقاً.
إعجاب واحد (1)
هل يمكن تمكين الإصدار على دلو files S3؟ هل النسخ الاحتياطي لـ AWS هو الطريقة الموصى بها لعمل نسخ احتياطية لدلاء S3 لـ Discourse؟
إعجاب واحد (1)
نعم.
يعد استخدام الإصدار، أو المزامنة إلى منطقة مختلفة، كلها استراتيجيات جيدة.
4 إعجابات