انشر مشروعك

إذا كان زر Publish أو Update يعرض "Your Cloud Balance is insufficient to publish" أو "Your Cloud Balance is insufficient to update," فهذا يعني أن محفظة Cloud الخاصة بك قد نفدت.

لإصلاح ذلك:

1. انتقل إلى Settings > Cloud & AI للتحقق من رصيدك الحالي.

2. حدّد Top up now وأضف أموالاً إلى محفظة Cloud الخاصة بك.

3. ارجع إلى لوحة Publish وحاول مرة أخرى.

ملاحظة: محفظة Cloud منفصلة عن رصيد اشتراكك. تموّل محفظة Cloud خدمات الاستضافة والنشر، بينما يُستخدم رصيد الاشتراك لمحادثات Agent المعتمدة على الذكاء الاصطناعي.

1. تحقق من عرض استخدام التخزين وحدد أكبر المحادثات والمشاريع والملفات.
2. نزّل أو انسخ احتياطيًا أي شيء قد تحتاج إليه لاحقًا.
3. احذف العناصر غير الضرورية فقط. إذا كان حذف المحادثة يتيح إزالة بيانات القرص المرتبطة، فحدّد هذا الخيار فقط بعد التأكد من أن حذف البيانات آمن.
4. حدّث الصفحة وتأكد من أن مساحة التخزين المتاحة قد زادت.
5. ارجع إلى Publish وأعد المحاولة مرة واحدة.

قد يكون الحذف دائمًا وقد يؤدي إلى تعطّل مشروع يشير إلى ملف تمت إزالته. إذا لم ينخفض الاستخدام، فتواصل مع Support مع عرض التخزين، والباقة، ورابط المشروع، ووقت فشل النشر.

انتظر حتى ينتهي فحص الأمان، ثم راجع كل عنصر تم وضع علامة عليه قبل النشر.

1. حدّد Resolve All وافحص السلوك المتأثر. أصلح المشكلات التي تتعلق بالأسرار المكشوفة أو المصادقة أو الأذونات أو بيانات المستخدم أو الوصول الخارجي غير الآمن قبل الاستخدام في بيئة الإنتاج.
2. إذا كان من المحتمل أن يكون سر قد انكشف، فأزله من المشروع وقم بتدويره عبر المزوّد المعني قبل النشر.
3. شغّل الفحص مرة أخرى وتحقق من المسار المتأثر.
4. استخدم Publish Anyway فقط عندما يفهم مراجع مسؤول المخاطر المتبقية غير الحرجة ويقبلها. دوّن السبب وتجنب تجاوز مخاطر غير محلولة على موقع إنتاج.

إذا لم تتمكن من تحديد تأثير إحدى النتائج، فلا تنشره. تواصل مع Support أو مسؤول الأمان لديك مع نص النتيجة وأدلة منقحة.

1. اختبر عنوان URL الإنتاجي للمنصة والنطاق المخصص كلًّا على حدة. وقارن أيضًا بين الصفحة الرئيسية والصفحة المحددة أو مسار API الذي يفشل.
2. سجّل رمز الحالة الدقيق، وعنوان URL الكامل، والوقت والمنطقة الزمنية، وما إذا كان الفشل ثابتًا أو متقطعًا.
3. تحقق من أحدث حالة نشر وما إذا كان تغيير حديث في تبعية أو متغير بيئة أو قاعدة البيانات أو خدمة خارجية يتوافق مع بداية الفشل.
4. التقط أخطاء Console و Network ذات الصلة.

إذا استمر الفشل، فتواصل مع Support مع خطوات إعادة الإنتاج، والإصدار المتأثر، وبيانات تشخيص منقحة. قبل إرسال HAR أو مخرجات الأوامر أو لقطة شاشة، أزل ملفات تعريف الارتباط، وترويسات Authorization، وTokens، ومعلمات الاستعلام السرية، والبيانات الشخصية، ومعلومات الدفع.

إذا انتهت مهلة النشر أو أصبح الموقع المباشر غير متاح مؤقتًا:

1. تحقق مما إذا كان كل من النطاق الفرعي Prod الخاص بالمنصة و Preview غير متاحين، أو أن أحدهما فقط هو غير المتاح.

2. أبقِ صفحة الخطأ الحالية ظاهرة — لا تنقر Publish بشكل متكرر.

3. تحقق مما إذا كنت قد عدّلت مؤخرًا التبعيات أو نقاط بدء التشغيل أو اتصالات قاعدة البيانات، لأن هذه التغييرات قد تؤثر في النشر.

إذا استمرت المشكلة، فتواصل مع Support وضمّن:

- رابط المشروع وعنوان URL المباشر

- وقت الفشل ومنطقتك الزمنية

- رقم الإصدار ولقطة شاشة لصفحة الخطأ

- ما إذا كان Preview يعمل بشكل طبيعي

- ما إذا كنت قد عدّلت مؤخرًا التبعيات أو نقطة البدء أو اتصال قاعدة البيانات

إذا كانت لوحة Publish تعرض "latest" مع زر معطل، أو كانت عالقة على "Building":

1. لا تنقر Publish بشكل متكرر — فهذا لن يسرّع الأمور وقد ينشئ مهام بناء مكررة.

2. انتظر بضع دقائق ثم حدّث الصفحة.

3. إذا لم تتغير الحالة بعد التحديث، فتواصل مع Support.

ضمّن ما يلي عند التواصل مع Support:

- رابط المحادثة

- لقطة شاشة كاملة للوحة Publish (بما في ذلك عنوان URL للصفحة، ورقم الإصدار، وحالة الزر)

- وقت الحدوث ومنطقتك الزمنية

- رقم الإصدار المعروض حاليًا

- في أي خطوة بدأ عرض "Building" أو أصبح الزر معطلاً

1. تحقق مما إذا كانت الصورة مفقودة في عارض التطبيقات أو على الموقع المنشور أو في كليهما.
2. حدّد Reload App Viewer مرة واحدة. إذا كانت المشكلة على الموقع المباشر فقط، فتأكد من أن أحدث إصدار قد تم نشره أو تحديثه.
3. أخبر Agent بالصفحة، والصورة التي يجب أن تظهر، ومن أين جاءت الصورة أصلًا. واطلب منه التحقق من أن المشروع الحالي لا يزال يستخدم اسم الصورة الصحيح وموقعها الصحيح.
4. إذا تمت إزالة الصورة الأصلية أو إعادة تسميتها، فقم برفع الصورة المقصودة أو تحديدها مرة أخرى، ثم أعد اختبار الصفحة.
5. إذا كانت الصورة تستخدم تخزين التطبيق أو خدمة متصلة أخرى، فتأكد من أن الخدمة المقصودة متصلة وأن الملف لا يزال موجودًا هناك.

إذا استمرت الصورة في عدم التحميل، فتواصل مع Atoms Support مع Chat Link، وعنوان URL للصفحة المتأثرة، واسم الصورة أو مصدرها، ولقطة شاشة. لا تُضمّن روابط وصول خاصة أو كلمات مرور أو مفاتيح أو Tokens.

إذا تم تنزيل حزمة الاستضافة الذاتية المصدّرة بنجاح لكنها فشلت في التشغيل:

1. تحقق من README المضمّن في حزمة التصدير لمعرفة متطلبات البيئة وخطوات الإعداد.

2. تحقق من أن بيئة التشغيل لديك تطابق المتطلبات (إصدار نظام التشغيل، وإصدار Docker، وإصدار Node.js).

3. شغّل أمر بدء التشغيل وراجع المخرجات الكاملة بحثًا عن رسائل الخطأ.

إذا استمرت المشكلة، فتواصل مع Support وضمّن:

- إصدار التصدير ووقت التنزيل

- نظام التشغيل المستخدم وإصدار Docker

- الأمر الكامل الذي تم تنفيذه والمخرجات الكاملة

- السكربت الفاشل أو مسار API

- طريقة النشر المتوقعة

مهم: أرفق مثال إعدادات منقحًا، لكن لا تُضمّن كلمات مرور أو أسرارًا أو Tokens.

يعرض عارض التطبيقات والموقع المنشور مرحلتين مختلفتين من مشروعك. حفظ تغيير مرئي لا يحدّث الموقع المباشر بمفرده.

1. في Design، حدّد Save وانتظر حتى تنتهي مهمة Agent الحالية أو عملية البناء.
2. افتح Publish. يستخدم النشر أحدث إصدار من المشروع؛ ولا يوجد محدد إصدار في لوحة Publish.
3. حدّد Publish للإصدار الأول أو Update لإصدار لاحق. انتظر حتى تعرض اللوحة Up to date.
4. افتح الموقع المباشر في علامة تبويب جديدة وأعد تحميله مرة واحدة.
5. إذا كان عنوان Atoms الافتراضي يعرض التغيير لكن النطاق المخصص لا يعرضه، فتحقق من اتصال النطاق بدلًا من نشر الإصدار نفسه بشكل متكرر.

إذا كان الموقع المباشر لا يزال يعرض الإصدار الخاطئ، فتواصل مع Atoms Support مع Chat Link، وعنوان URL المباشر، والإصدار الذي كنت تنوي نشره، والوقت والمنطقة الزمنية، ولقطات شاشة من عارض التطبيقات والموقع المباشر.

1. احتوِ الخطر الفوري. إذا كان الإصدار يكشف بيانات حساسة أو ينشئ سلوكًا غير آمن، فافتح App Status واستخدم Pause لتطبيق مؤهل على سحابة Atoms أو Unpublish لإزالة الوصول العام. وإذا لم يكن هناك خطر نشط، فتجنب التسبب في انقطاع غير ضروري.
2. سجّل النطاق المتأثر، ووقت النشر، والإصدار الحالي، والإصدار المقصود، وتأثير العمل.
3. بعد توقف مهمة agent الحالية، افتح Versions، واختر آخر إصدار جيد معروف، وحدّد Restore this version.
4. تحقق من الإصدار المستعاد في Preview، بما في ذلك تدفقات تسجيل الدخول والدفع والبيانات الحرجة، ثم انشره أو حدّثه.

قد لا يؤدي استعادة إصدار المشروع إلى التراجع عن تغييرات قاعدة بيانات الإنتاج أو الإجراءات الخارجية. لا تستبدل بيانات الإنتاج أو تحذفها لمحاكاة التراجع. تواصل مع Support فورًا عندما تكون البيانات أو بيانات الاعتماد أو المدفوعات أو التغييرات المدمرة متضمنة.

1. أوقف مهمة agent الحالية أو انتظرها؛ لا يمكن استعادة إصدار أثناء وجود عمل متعارض نشط.
2. افتح Versions، وحدد آخر إصدار جيد معروف، ثم حدّد Restore this version.
3. راجع المشروع المستعاد في Preview واختبر التدفقات الحرجة التي تغيّرت.
4. انشر أو حدّث فقط بعد أن تكون نتيجة Preview صحيحة.

لا يعني استعادة إصدار المشروع بالضرورة التراجع عن سجلات قاعدة بيانات الإنتاج، أو تغييرات المخطط، أو متغيرات البيئة، أو المدفوعات، أو رسائل البريد الإلكتروني، أو الإجراءات الخارجية الأخرى. إذا كان الإصدار قد غيّر بيانات الإنتاج أو كان الإصدار المستهدف غير متاح، فتوقف وتواصل مع Support مع رقمي الإصدارين، والنطاق المتأثر، ونتيجة الحفاظ على البيانات المطلوبة.

الإيقاف المؤقت وإلغاء النشر إجراءان مختلفان:

الإيقاف المؤقت (لمشاريع سحابة Atoms فقط):

- يصبح التطبيق غير متاح للزوار.

- تبقى موارد الخادم مخصصة وتستمر الفوترة.

- يمكنك استئناف التطبيق في أي وقت من App Status.

إلغاء النشر (جميع المشاريع):

- يتوقف الموقع الإلكتروني تمامًا عن العمل. ويفقد أي شخص يستخدم عنوان URL المنشور إمكانية الوصول.

- بالنسبة إلى مشاريع سحابة Atoms، يتم تحرير موارد الخادم.

- يمكنك نشر المشروع مرة أخرى لاحقًا، لكن لا يمكن للزوار الوصول إليه حتى تفعل ذلك.

استخدم الإيقاف المؤقت للإزالة المؤقتة مع إعادة تشغيل سريعة. واستخدم إلغاء النشر لإزالة الموقع بالكامل.

إذا كان متصفحك يعرض "too many redirects" أو كانت الصفحة تستمر في إعادة التحميل دون عرض محتوى:

1. جرّب النطاق الفرعي Prod الافتراضي للمنصة (وليس نطاقك المخصص) لتحديد ما إذا كانت حلقة إعادة التوجيه ناتجة عن إعداد النطاق أو عن التطبيق نفسه.
2. إذا كان النطاق الفرعي Prod الافتراضي يعمل، فتحقق من إعدادات DNS لنطاقك المخصص ومن مسجل النطاق لديك بحثًا عن قواعد إعادة توجيه قد تتعارض مع المنصة.
3. امسح ذاكرة التخزين المؤقت للمتصفح أو اختبر في نافذة التصفح الخفي لاستبعاد عمليات إعادة التوجيه المخزنة مؤقتًا.

إذا استمرت المشكلة، فتواصل مع Support وضمّن:

- عنوان URL الكامل الذي يعرض حلقة إعادة التوجيه

- ما إذا كان النطاق الفرعي Prod الافتراضي متاحًا

- اسم النطاق وموفر DNS

- لقطة شاشة كاملة للخطأ

إذا كان تطبيقك يعمل في Preview لكنه يفشل في الإنتاج بسبب متغيرات بيئة مفقودة أو فارغة:

1. تحقق مما إذا كان متغير البيئة قد تم حفظه قبل آخر عملية نشر أو بعدها. إذا تم حفظه بعدها، فأنت بحاجة إلى النشر مرة أخرى حتى يسري التغيير.
2. تحقق من أن المتغير مضبوط للبيئة الصحيحة (Development مقابل Production).
3. تحقق مما إذا كانت رسالة الخطأ من الخدمة التابعة تعطي دلالة — على سبيل المثال، تعني "unauthorized" غالبًا أن مفتاح API فارغ أو غير صحيح في تلك البيئة.

إذا استمرت المشكلة، فتواصل مع Support وضمّن:

- رابط المشروع أو عنوان URL المباشر

- اسم المفتاح المتأثر وأي بيئة فيها المشكلة

- الخطأ الكامل من الخدمة التابعة

- لقطة شاشة منقحة لصفحة الإعدادات

- ما إذا كان الإعداد قد تم حفظه قبل النشر أو بعده

مهم: قدّم أسماء المفاتيح فقط. لا ترسل القيم السرية أو كلمات المرور أو Tokens.

قد تستخدم النتائج صياغة متشابهة مع أنها تشير إلى مواقع مختلفة. ولا تعني الصياغة المتشابهة بالضرورة أن النتائج مكررة.

1. قارن بين اسم النتيجة والموقع المعروض لكل نتيجة.
2. راجع كل موقع فريد بدلًا من تجاهل الصياغة المتكررة.
3. إذا كانت عدة نتائج لها السبب الجذري نفسه، فأصلح ذلك السبب ثم تحقق من كل موقع مرة أخرى.
4. شغّل فحص الأمان مرة أخرى على الإصدار المحدّث.

إذا استمرت النتيجة نفسها والموقع نفسه في الظهور أكثر من مرة، فتواصل مع Atoms Support مع Chat Link، ووقت الفحص والمنطقة الزمنية، وعدد النتائج، ولقطة شاشة منقحة. أزل أي كلمات مرور أو مفاتيح أو Tokens أو معلومات حساسة أخرى قد تظهر في إحدى النتائج.

يُعد الفحص المكتمل الذي لا يعرض أي نتائج مُبلّغ عنها تحققًا مفيدًا، لكنه لا يضمن العثور على كل مشكلة أمنية أو مشكلة وقت تشغيل. يفحص الفحص إصدار المشروع المحدد؛ ولا يزال تطبيقك بحاجة إلى الاختبار بالطريقة التي سيستخدمه بها المستخدمون الحقيقيون.

قبل النشر، اختبر الرحلات المهمة في تطبيقك، بما في ذلك تسجيل الدخول، وأدوار المستخدمين، والوصول إلى البيانات الخاصة، والمدفوعات، والخدمات المتصلة. استخدم حسابات اختبار منفصلة للأدوار المختلفة وتأكد من أن كل حساب يمكنه الوصول فقط إلى المعلومات والإجراءات المقصودة له.

إذا اكتشفت مشكلة في الإنتاج قد تكشف حسابات أو بيانات خاصة أو مدفوعات أو بيانات اعتماد، فأوقف استخدام الميزة المتأثرة أو قيّد الوصول إليها أولًا. قم بتدوير أي بيانات اعتماد قد تكون انكشفت، ثم تواصل مع Atoms Support مع Chat Link، والإصدار المتأثر، وخطوات إعادة إنتاج المشكلة، والوقت والمنطقة الزمنية، ولقطة شاشة منقحة. لا تشارك بيانات الاعتماد المكشوفة نفسها.

إذا أبلغ الفحص أن إجراءً خاصًا بالمسؤول قد يكون غير محمي، فتعامل مع النتيجة على أنها غير محلولة حتى تؤكد أن المستخدمين غير المصرح لهم لا يمكنهم استخدامه. لا يكفي إخفاء زر المسؤول إذا كان لا يزال من الممكن طلب الإجراء بطريقة أخرى.

1. افتح النتيجة وحدد الإجراء أو الموقع الذي تسميه.
2. قرر أي الأدوار المسجّلة الدخول يجب أن يُسمح لها باستخدام ذلك الإجراء.
3. اطلب من Agent التحقق من إذن المستخدم عند طلب الإجراء، وليس فقط عند عرض الزر.
4. اختبر الإجراء أثناء تسجيل الخروج، ومع حساب اختبار عادي، ومع حساب اختبار مسؤول مصرح له.
5. تأكد من أن المحاولات المرفوضة لا تكشف أي بيانات خاصة ولا تُحدث أي تغييرات، ثم شغّل فحص الأمان مرة أخرى.

لا تنشر الميزة المتأثرة إذا كان لا يزال بإمكان حساب غير مصرح له استخدام الإجراء. تواصل مع Atoms Support مع Chat Link، ونص النتيجة، والإصدار المتأثر، ولقطة شاشة منقحة إذا لم تتمكن من حلها.

يحمي HTTPS المعلومات أثناء انتقالها بين المستخدم والخدمة. إذا أبلغ الفحص عن مشكلة HTTPS، فاستخدم النتيجة الدقيقة لتحديد العنوان أو المورد أو رد النداء أو إعداد النطاق المتأثر.

1. افتح النتيجة ولاحظ الموقع والعنوان الدقيقين اللذين يبلّغ عنهما.
2. اطلب من Agent استبدال ذلك الاتصال المحدد بالعنوان الآمن الذي يدعمه مزوّده، أو تصحيح إعداد النطاق ذي الصلة.
3. لا تتجاهل تحذيرات الشهادة ولا تغيّر عنوانًا بشكل عشوائي إذا لم تكن الخدمة الخارجية توثق بديلاً آمنًا مكافئًا.
4. أعد اختبار رحلة المستخدم المتأثرة وتأكد من عدم إرسال أي كلمة مرور أو Token أو تفاصيل دفع أو معلومات خاصة عبر اتصال غير آمن.
5. شغّل فحص الأمان مرة أخرى على الإصدار المحدّث.

إذا كانت النتيجة تتعلق بنطاق مخصص أو شهادة لا يمكنك تصحيحها، فتواصل مع Atoms Support مع Chat Link، وعنوان URL المتأثر، ونص النتيجة، والوقت والمنطقة الزمنية، ولقطة شاشة منقحة.

Row Level Security، أو RLS، هي ميزة في Supabase تتحكم في صفوف قاعدة البيانات التي يمكن لكل مستخدم قراءتها أو تغييرها. تكون هذه النتيجة ذات صلة فقط عندما يستخدم المشروع Supabase ويحدد الفحص جدولًا تحتاج قواعد الوصول الخاصة به إلى مراجعة.

1. افتح النتيجة وحدد الجدول الذي تسميه.
2. دوّن من يجب أن يكون قادرًا على عرض بيانات ذلك الجدول أو إضافتها أو تعديلها أو حذفها.
3. اطلب من Agent إنشاء سياسات Supabase الأقل سماحًا التي تدعم رحلات المستخدم تلك.
4. اختبر أثناء تسجيل الخروج ومع حساب اختبار منفصل لكل دور. وتأكد من أن كل حساب يمكنه الوصول فقط إلى الصفوف والإجراءات المقصودة.
5. شغّل فحص الأمان مرة أخرى بعد تطبيق السياسات.

لا تعطل RLS ولا تسمح لكل مستخدم فقط لإزالة التحذير. قبل إجراء تغيير قد يؤثر في البيانات الحالية، أكد الخطة واحتفظ بنسخة احتياطية أو تصدير آمن عند الاقتضاء. لا تشارك أبدًا مفاتيح Supabase أو بيانات اعتماد قاعدة البيانات في Chat أو لقطات الشاشة.