يتم استدعاء هذا فقط عند الرفع الآمن. أعتقد أنك قمت بتكوينه في الماضي، وبما أنك أزلته الآن.
ما الذي يعيده هذا؟
./launcher enter app
rails c
> Upload.where('secure').count
(أيضًا، لدينا خطأ في التسمية في site_setting.rb:157:in absolute_base_url؛ يجب أن يُسمى s3_absolute_base_url)
مرحبًا سام،
شكرًا جزيلاً لك على إلقاء نظرة في ذلك!
حسنًا، soweit ما أعرفه، لم نفعّل ميزة التحميل الآمن. ولكن بما أنني لست المدير الوحيد، لا يمكنني الجزم بذلك. وإذا فهمت الأمر بشكل صحيح، فيجب أن يعيد العداد القيمة 0 عندما لا تكون الميزة قد فُعّلت مطلقًا؟ حسنًا، الرقم أكبر بكثير من 0 
بل هو 235 في الواقع 
هذا الأمر يعيد
[1] pry(main)> Upload.where('secure').count
=> 235
[2] pry(main)>
هل هناك أي شيء يمكنني فعله لإصلاح ذلك؟
هل يجب أن أتعطّل إعداد السماح للمedia الآمنة بتضمين الصور في الرسائل؟
هل يستحق الأمر تجربة تفعيل media الآمنة ثم تعطيلها بعد ذلك؟
شكرًا جزيلاً لك على محاولة المساعدة هنا!
إذا لم تكن الوسائط الآمنة مفعلة حاليًا، فلا داعي لتفعيلها. يجب أن تكون قد فُعّلت في مرحلة ما نظرًا لعدد الرفع الآمن الذي لديك. جرّب تشغيل مهمة rake uploads:secure_upload_analyse_and_update؛ ستقوم هذه المهمة بمراجعة جميع الرفع لديك ووضع علامة عليها على أنها آمنة أو غير آمنة بناءً على إعدادات الموقع (إذا كانت الوسائط الآمنة معطلة، فسيتم وضع علامة على جميعها على أنها غير آمنة).
مرحبًا مارتين،
شكرًا جزيلاً لك. سأجرب هذا الليلة.
فقط للتأكد من فهمي الصحيح، لدينا حاليًا مُفعّل:
هل يجب علينا تفعيل هذا الخيار أيضًا؟ أم أن هذا لا يؤثر على عملية التصنيف؟
وللتوضيح فقط، بعد أمر rake، هل عليّ إعادة بناء التطبيق؟ أم أن هذا غير ضروري، لكنه ربما موصى به؟
شكرًا جزيلاً!
هذا الخيار مفعّل افتراضيًا، لكنه لا يفعل شيئًا ما لم يكن وسيط آمن مفعّلًا.
لا أعتقد أن إعادة البناء ضرورية؛ لقد قمت بتشغيل هذا على مواقع حية دون أي مشاكل.
شكرًا جزيلاً لك!
سأجرب وسأبلغ غدًا.
شكرًا شكرًا!
أنا أتخيل، لكن تتبع الخطأ يبدو أنه يحاول تسلسل قائمة من الرسائل، أو قائمة من المعلومات المستمدة من الرسائل، ويفشل عند محاولة تسلسل صورة معينة. يُفترض أن هذه الصورة هي صورة الملف الشخصي لمستخدم. يتأثر حساب واحد فقط، لذا ربما تكون الصورة المعيبة تابعة لمستخدم تواصل فقط مع هذا الحساب المتأثر.
ربما يكون بناء القائمة الفاشل مخصصًا لآخر N رسالة. ربما يمكنك إرسال N رسالة (عناوين مواضيع مختلفة) إلى الحساب المتأثر، بحيث تحتوي القائمة فقط على رسائل سليمة؟
شكرًا لك مجددًا يا مارتن على النصيحة.
لقد حاولت تشغيل الأمر rake uploads:secure_upload_analyse_and_update، لكن الناتج كان:
هذا الإجراء يعمل فقط مع التخزين الخارجي.
لذلك حاولت تفعيل خيار تفعيل الوسائط الآمنة. ولكن للأسف، أو لنقل لتجنب أخطاء المشرفين، لا يمكن تفعيل هذا الخيار إلا عن طريق تكوين أحواض Amazon S3. وأنا متأكد تمامًا من أن أحدًا لم يقم أبدًا بإعداد S3 من قبل.
وبالتالي لا يمكنني تشغيل سكريبت Rake لأنني لا أملك أي تخزين S3 متاح. لذا لا يمكنني الجزم فيما إذا كان لذلك تأثير على الأمر pry(main)> Upload.where('secure').count.
أنا أتساءل: لماذا لا تزال لدينا بعض الرفع الآمن بينما لم نفعّل S3 أبدًا؟
هل لديك أي تلميحات حول ذلك؟
لكن في الواقع،
نجح هذا الحل. لذا أنا بخير حاليًا، حتى لو لم أكن أعرف السبب وراء هذا السلوك. سأكون سعيدًا لو تعلمت ما قد يكون السبب الآخر.
شكرًا مقدّمًا، وشكرًا على كل الوقت الذي قضيتَه بالفعل.
حسنًا يا Ed_S، ماذا أقول سوى:
في الواقع، كانت تلميحك الصغير هو الذي نجح. لقد كتبت رسالة واحدة جديدة ونشرت إجابة أخرى، ثم اختفى الخطأ.
حتى لو كنت بطلًا في هذه اللحظة، فهذا لا يعفيك من المزيد من الأسئلة آمل أن تكون موافقًا على مساعدتي في فهم ما حدث هنا بالضبط.
أولاً، لمساعدتي على فهم كيفية قراءة السجلات بشكل أفضل. أعني، ما تقدير رائع قدمته! ما الذي دفعك إلى الاعتقاد بأن مشكلة في التسلسل (serialization) هي السبب في هذا الخلل؟
lib/url_helper.rb:90:in `cook_url'
app/models/topic.rb:126:in `image_url'
app/serializers/listable_topic_serializer.rb:34:in `image_url'
لماذا ليس cook_url أو أي شيء آخر لا أعرفه؟
ثانيًا، ما هي العلامات التحذيرية التي يجب أن أنتبه لها لتجنب الوقوع في مشكلة مماثلة مرة أخرى؟ أم ربما مع مستخدم آخر؟
هل تعتقد أنه يمكن تضييق النطاق لتحديد الرسالة أو المستخدم أو الصورة التي تسببت في المشكلة؟ هل هناك أي طريقة أخرى لفحص ذلك غير … النقر عبر الرسائل والأمل في ملاحظة تأثير على أحد منشورات الرسائل الخاصة؟
المضحك أن بعض المشرفين قاموا بنفس الشيء تمامًا، مثل كتابة رسالة جديدة (موضوع) للحساب المتأثر، ولم نلاحظ أي سلوك آخر. بطريقة ما، كانت آخر رسالة أرسلتها أنا إلى الحساب المتأثر هي التي نجحت.
وأخيرًا، هل يمكنني الحصول على رقم هاتفك للاتصال بك في حالات الطوارئ؟ مجرد نكتة!
لكن بجدية، شكرًا جزيلاً، شكرًا كثيرًا، شكرًا لا يُحصى. لقد علقت حقًا هنا، وأنا سعيد جدًا لأن مستخدمنا – وكما ذكرت، أحد مشرفينا – قد عاد إلى المسار الصحيح. شكرًا لك يا Ed_S!
تخمين رائع!
ها ها - يبدو أنني حظيت بحظ سعيد. الأمر المتعلق بتتبع المكدس (stack trace) هو أنه يعمل من الخاص إلى العام - فهو ليس مجرد قائمة من الأشياء، بل هو صورة للتفاعلات المتداخلة من الكود العام وصولاً إلى الآلية المحددة. لذا، بدت فكرة ‘الصورة’ مثيرة للاهتمام، لأن قائمة الرسائل تحتوي فقط على صور الملفات الشخصية. وأعتقد أننا شهدنا مشاكل غريبة مع صور الملفات الشخصية من قبل.
لكنني لا أعرف لماذا يبحث الكود في التخزين الآمن، إذا لم تكن قد استخدمته من قبل.
أشك في أن استعلام قاعدة بيانات يمكنه سرد الصور التي سيتم جلبها في هذه الحالة، لكنني لا أعرف كيف يمكنك العثور على الملف الشخصي المشبوه. إذا كان هذا بالفعل القصة الكامنة وراء تتبع المكدس.
هناك مهمة rake لإصلاح هذا:
./launcher enter app
rake uploads:secure_upload_analyse_and_update
أوصي بتشغيلها.
مرحبًا سام،
شكرًا جزيلاً لك على بقاء هذا الأمر في قائمتك. أنا سعيد جدًا بالحصول على مساعدة إضافية لتوضيح هذا الأمر.
لقد جربت ما يلي:
ولكن في الواقع، ظهر نفس المخرج الذي يشير إلى أن هذا الأمر يعمل فقط مع تخزين S3 الخارجي، وبما أننا لم نقم بإعداد واحد بعد، فأنا أشعر بالضياع قليلًا.
إليك مخرجات وحدة التحكم الخاصة بي:
./launcher enter app
rake uploads:secure_upload_analyse_and_update
This task only works for external storage.
هل هناك شيء فاتني؟ أم أن هذه مشكلة تقنية، وكان من المفترض أن يعمل الأمر حتى مع إيقاف تشغيل secure media؟
شكرًا على خبرتك.
في الواقع، أحيانًا يكون الحظ هو ما يبقينا على قيد الحياة، أليس كذلك؟
ومع ذلك، شكرًا لك، لقد شعرت بالإحباط قليلًا، وكان حذف جميع الرسائل مجرد خيار أخير.
حسنًا، ربما يمكنك إعطائي بعض التلميحات حول الموضوعات هنا. بالنسبة لي، كونني جديدًا نسبيًا على Docker وDiscourse، فإن اقتراحك بتشغيل استعلام قاعدة بيانات يجعلني أشعر بالضياع قليلًا. ما هي قاعدة البيانات التي يستخدمها Discourse؟ وهل يمكنني فعل شيء مثل:
./launcher enter app
mysql select bla
أم أنها MongoDB؟ ولكن الدخول إلى الحاوية وتشغيل الاستعلام بداخلها هو على الأقل الطريق الصحيح، أليس كذلك؟
وهل توجد قائمة بحقول أو خصائص يمكنني تصفحها، مثل مرجع أو شيء مشابه، حتى أتمكن من طرح بعض الأفكار حول الاستعلام الصحيح؟
ولكن فقط لتوضيح الأمر، حتى لو تمكنت من الحصول على قائمة صور الملفات الشخصية في قائمة الوارد – فلا يزال هناك اقتراح لتضييق النطاق لمعرفة أيها الشخص السيء أو ما يجب فعله حتى لو وجدناه، أليس كذلك؟ هل لديك أي أفكار حول ذلك ربما؟
علاوة على ذلك، أنا مندهش من وجود مشاكل شائعة مع صور الملفات الشخصية. هل هناك موضوع محدد يمكنني قراءته للحصول على مزيد من الأفكار حول ذلك؟ أو ربما نوع من الدليل حول كيفية التعامل مع صور الملفات الشخصية أو تقييد استخدامها أو شيء من هذا القبيل؟ لتجنب مثل هذه المشاكل؟
Ed_S، شكرًا جزيلاً لك على البقاء معي.
لا أعرف الكثير عن جانب قاعدة البيانات، لكنني أوصي بإضافة Data Explorer التي تُعد إضافة مدعومة رسميًا، وهذا الموضوع. (من الأفضل بدء موضوع جديد إذا كانت لديك أسئلة جديدة - فقد يستفيد الآخرون من النقاش، وسيعود عنوان موضوع مناسب بمزيد من المساعدة.)
تعديل: ربما يمكنك أيضًا الاطلاع على
حيث توجد إشارات إلى كيفية عمل الآلية وكيف يمكنك استعلامها.
مرحبًا Ed_S،
شكرًا جزيلاً على التلميحات. إضافة Data Explorer رائعة! فهي نقطة انطلاق ممتازة للتحليلات الأعمق!
كما كانت التلميح المتعلق بالصور الرمزية المفقودة مفيدًا. قمت بالتحقق من الأمر وبدوًا كل شيء على ما يرام. لذا شكرًا جزيلاً لمشاركتك هذه الرؤية.
حسنًا، طالما أن الأمور تعمل حاليًا، فأنا سعيد جدًا. أصب يديّ على أن يستمر هذا الوضع
شكرًا مجددًا يا Ed_S على المساعدة المستمرة.
إذا واجه أي شخص آخر مثل هذا الخطأ، فيرجى إخباري بما واجهته أو ما يمكن فعله لمنع حدوث مثل هذه الأخطاء.
شكرًا للجميع على القراءة.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.