No they aren’t and they got structure internally. Just wanted to ensure that it’s okay to see only 2 folders and nothing else there.
Now that’s VERY useful information. Maybe not include Option 2 at all since it could break many things. Infact in option 1 I’d probably highlight that one shouldn’t change the bucket for the uploads since it would require a rebake etc, only change the bucket for backups.
This is exactly what was looking for, don’t touch the upload, just move Backups to a new bucket or a sub folder.
مرحباً،
واجهتُ مشكلةً مماثلة لكن لسبب مختلف. فقد نجحت عمليات الرفع إلى سلة النسخ الاحتياطي، لكن سلة الرفع لم تعمل.
اتضح أن السبب هو أن سلة الرفع مُعدة لمنع جميع الوصول العام. (وأعتقد أن هذا هو الإعداد الافتراضي حالياً). فعندما اختبرت الرفع محلياً، سار كل شيء على ما يرام، لكن Discourse كانت ترفع الملفات بصلاحيات “public-read”، فرفضت خدمة S3 ذلك. (كنتُ أتوقع أن تقوم S3 بحفظ حالة “public-read” على الملف، ثم ترفض محاولات الوصول العام.) وقد انتهى بي الأمر إلى إضافة سجلات إضافية بشكل يدوي لمعرفة الخيارات المستخدمة في عملية الرفع.
ربما يمكن لـ Discourse استخدام واجهة برمجة التطبيقات GetPublicAccessBlock للتحقق مما إذا كانت السلة مُعدة بشكل صحيح عند إعداد خيار “سلة رفع S3”؟
إحدى الاحتمالات الأخرى هي أن نبدأ بتوصية المستخدمين بوضع شبكة توصيل محتوى (CDN) من CloudFront أمام سلة التحميلات الخاصة بهم في دليل الإعداد، وفي هذه الحالة يجب أن يبقى حظر القراءة العامة ساريًا.
لست متأكدًا من كيف يجب أن يبدو التوازن بين التكلفة والتعقيد في هذه الحالة.