لدي متجر على منصة **سلة** مرتبط بـ **تطبيق خاص (Private App)** مبني باستخدام **Laravel 10** ومستضاف على **Hostinger**.
التطبيق يعمل داخل لوحة تحكم التاجر (Embedded App) ويحتوي على:
* لوحة تحكم داخل سلة. * إعدادات التطبيق. * استقبال Webhooks الخاصة بالطلبات.
## المشكلة
يظهر أحيانًا عند فتح التطبيق من لوحة سلة الخطأ:
**403 — Invalid Salla merchant**
أحتاج إلى تشخيص السبب الحقيقي وإصلاحه، والتأكد أن التطبيق يعمل بشكل طبيعي عند تشغيله من **"تطبيقاتي" داخل لوحة التاجر**.
## المطلوب
* تشخيص سبب ظهور خطأ **403** عند الإطلاق الحقيقي من سلة وإصلاحه. * التأكد أن `merchant_id` يصل من سلة ويتم التحقق منه بشكل صحيح. * اختبار Webhook من خلال إنشاء طلب تجريبي والتأكد من وصول حدث `order.created` وتسجيله في قاعدة بيانات التطبيق. * بعد الانتهاء إعادة:
* `LOG_LEVEL=error` * تنظيف Cache الخاص بـ Laravel. * تقديم تقرير مختصر يوضح:
* سبب المشكلة. * الملفات التي تم تعديلها. * سبب كل تعديل.
## معلومات مهمة
* توجد أداة فحص جاهزة تعرض حالة النظام بالكامل، وجميع الفحوصات الحالية ناجحة. * الطلب اليدوي باستخدام `merchant_id` الصحيح يعمل ويرجع **200 OK**. * نظام Webhooks يدعم التحقق عبر Authorization Token و HMAC Signature. * سيتم توفير وصول مؤقت إلى:
* hPanel أو SSH. * لوحة سلة Partners. * لوحة التاجر (أو عبر AnyDesk / TeamViewer عند الحاجة).
## شروط العمل
* يمنع نهائيًا إعادة توليد مفاتيح التطبيق في Salla Partners. * يمنع إجراء أي تعديلات خارج نطاق المشكلة دون الرجوع إليّ. * يجب أخذ نسخة احتياطية من أي ملف قبل تعديله. * العمل سيكون مباشرة على بيئة الإنتاج، لذلك أحتاج إلى شخص لديه خبرة فعلية وليس للتجربة.
## شرط مهم قبل قبول العرض
أرجو ذكر أعمال سابقة مع **تطبيقات سلة المدمجة (Embedded Apps)** أو **Salla Webhooks** أو **OAuth / Partners API**، مع توضيح طبيعة العمل الذي قمت به.
## معيار قبول التسليم
* فتح التطبيق من "تطبيقاتي" داخل لوحة سلة بدون ظهور خطأ 403. * نجاح استقبال حدث `order.created` وإنشاء السجل داخل قاعدة البيانات. * إعادة `LOG_LEVEL=error` وتنظيف الكاش. * تسليم تقرير مختصر بجميع التعديلات التي تمت.
قرأت تفاصيل طلبك بدقة، وأدرك تماماً حساسية الخطأ 403 Invalid Salla merchant في التطبيقات المدمجة (Embedded Apps). غالباً ما تعود هذه المشكلة إلى قيود المتصفحات على الـ Cookies والـ Session (مثل إعدادات SameSite و Secure) داخل الـ iframe الخاص بلوحة سلة، أو آلية التحقق من الـ merchant_id في الـ Middleware عند الإطلاق الحقيقي.
أنا مطور Laravel متخصص في بناء وتطوير تطبيقات سلة المدمجة، والربط مع الـ Partners API / OAuth 2.0، وإدارة الـ Webhooks.
ما سأقوم بتنفيذه بدقة واحترافية: تشخيص وإصلاح خطأ 403: فحص مسار التحقق من التاجر وضمان استقرار الجلسة وتمرير الـ merchant_id بشكل صحيح داخل الـ iframe.
اختبار الـ Webhook: التأكد من استقبال حدث order.created وتسجيله في قاعدة البيانات مع التحقق الآمن عبر الـ HMAC Signature.
تنظيف البيئة: إعادة الـ LOG_LEVEL=error وتنظيف كاش Laravel بالكامل (php artisan optimize:clear).
التقرير النهائي: تقديم تقرير مختصر ومحدد بالملفات المعدلة وأسباب التعديل.
التزامي التام بشروطك: لن يتم إعادة توليد (Regenerate) أي مفاتيح للتطبيق في Salla Partners نهائياً.
أخذ نسخة احتياطية (Backup) من أي ملف قبل تعديله، والالتزام التام بنطاق المشكلة على بيئة الإنتاج في Hostinger.
سابقة أعمالي في بيئة سلة: تطوير تطبيقات مدمجة (Embedded) تعمل بكفاءة داخل لوحة التاجر، وحل مشاكل الـ Session والـ CORS الخاصة بها.
بناء مستمعات Webhooks متقدمة لمعالجة الطلبات (order.created) مع توثيق الـ X-Salla-Signature.
إدارة كاملة لعمليات الـ OAuth وتجديد الـ Tokens تلقائياً للتاجر.
جاهز للبدء فوراً وتسيلم العمل بالشكل المطلوب والمستقر.
قرأت تفاصيل طلبك بدقة. مشكلة خطأ 403 Invalid Salla merchant عند الإطلاق الحقيقي للتطبيقات المدمجة (Embedded Apps) داخل الـ iframe غالباً ما تتعلق بقيود المتصفحات على الـ Sessions والـ Cookies (مثل إعدادات SameSite=None و Secure في Laravel)، أو بسبب اختلاف آلية التحقق من الـ merchant_id في الـ Middleware بين الطلب اليدوي والطلب الفعلي القادم من سلة.
أنا مطور Laravel متخصص في تطبيقات سلة المدمجة، والـ OAuth 2.0، وإدارة الـ Webhooks.
خطة العمل والتنفيذ: إصلاح خطأ 403: تشخيص مسار التحقق وتعديل إعدادات الجلسة والـ Middleware لضمان التعرف على التاجر بنجاح داخل لوحة سلة.
اختبار الـ Webhook: إرسال طلب تجريبي للتأكد من استقبال حدث order.created وتسجيله في قاعدة البيانات مع التحقق من الـ HMAC Signature.
إنهاء العمل: إعادة الـ LOG_LEVEL=error، تنظيف الكاش بالكامل، وتسليم تقرير مختصر بالملفات المعدلة وأسباب التعديل.
التزام تام بشروطك: لن يتم إعادة توليد مفاتيح التطبيق نهائياً.
أخذ نسخ احتياطية من الملفات قبل تعديلها، والعمل المباشر والآمن على استضافة Hostinger.
خبرات سابقة ذات صلة: بناء وتطوير تطبيقات مدمجة (Embedded Apps) تعمل بسلاسة داخل لوحة التاجر وحل مشاكل الـ CSRF والـ Iframes الخاصة بها.
ربط الـ Salla Webhooks ومعالجة أحداث الطلبات وتوثيق الـ Signature لحماية التطبيق.
إدارة الـ Access/Refresh Tokens وتجديدها تلقائياً عبر الـ API.
اطلعت على تفاصيل المشروع، وأفهم طبيعة المشكلة المتعلقة بخطأ 403 - Invalid Salla merchant في تطبيقات سلة المدمجة (Embedded Apps). هذا النوع من المشاكل غالبًا يكون مرتبطًا بآلية التحقق من التاجر عند تشغيل التطبيق من لوحة سلة، أو بطريقة استقبال بيانات الـ OAuth و"merchant_id" أثناء عملية الإطلاق.
لدي خبرة عملية في تطوير تطبيقات سلة باستخدام Laravel، وعملت على تطوير تطبيق Obix، بالإضافة إلى تطوير وتخصيص ثيمات سلة مثل عالي وملاك، كما لدي خبرة في التعامل مع Salla Partners API وOAuth وWebhooks وربط التطبيقات المدمجة داخل لوحة التاجر.
سأقوم بـ:
- تشخيص السبب الحقيقي لظهور خطأ 403 وإصلاحه دون إجراء أي تعديلات خارج نطاق المشكلة. - التأكد من وصول والتحقق الصحيح من "merchant_id" أثناء تشغيل التطبيق من لوحة "تطبيقاتي". - اختبار Webhook عبر إنشاء طلب تجريبي والتأكد من استقبال حدث "order.created" وتسجيله في قاعدة البيانات. - أخذ نسخة احتياطية من الملفات قبل أي تعديل. - إعادة "LOG_LEVEL=error" بعد الانتهاء، وتنظيف Cache الخاص بـ Laravel. - تسليم تقرير مختصر يوضح سبب المشكلة، والملفات التي تم تعديلها، وسبب كل تعديل.
ألتزم بعدم إعادة توليد مفاتيح التطبيق أو إجراء أي تغيير خارج نطاق العمل إلا بعد الرجوع إليكم، مع الحرص على تنفيذ التعديلات بأمان نظرًا لأن العمل سيكون على بيئة الإنتاج.
قرأت تفاصيل مشكلتك التقنية بدقة متناهية؛ وبصفتي Full-Stack Developer متخصص في Laravel وربط الـ APIs وإدارة سيرفرات Hostinger (hPanel/VPS)، أعلم تماماً أبعاد هذا الخطأ الخبيث وتحديداً في التطبيقات المدمجة (Embedded Apps) التي تعمل داخل الـ Iframe الخاص بلوحة تحكم تاجر سلة.
تشخيصي الأولي لسبب ظهور خطأ 403 — Invalid Salla merchant بشكل متقطع يعود غالباً إلى آلية التحقق من الـ OAuth Context أو الـ Merchant Verification Middlewares. عند فتح التطبيق كـ Embedded App، تمرر سلة الـ merchant_id عبر الـ Request الـمُوقع (Signed Parameter / Bearer Token)؛ وإذا حدث مشكلة في فك تشفير الـ Token، أو تداخل في جلسة العمل (Session Cookies SameSite/Secure بسبب قيود الـ Iframe في المتصفحات الحديثة)، أو عدم تحديث الـ Access/Refresh Token للتاجر بشكل صحيح في قاعدة البيانات، يرفض التطبيق الطلب بـ 403.
خطة العمل التشخيصية والإصلاحية بدقة: فحص الـ Middleware والـ Session Security: التحقق من ملفات الـ Middleware المسؤولة عن فحص الـ merchant_id الوارد من سلة وتتبع أين يفشل التحقق بالضبط (Verification Logic). ضبط إعدادات الـ Cookies في ملف config/session.php لتدعم same_site => 'none' و secure => true لأن التطبيقات المدمجة تعمل داخل Iframe، وبدون هذا الضبط قد تحجب المتصفحات كوكيز الجلسة وتتسبب في الـ 403.
تأمين وفحص الـ Webhooks:
مراجعة خوارزمية التحقق من الـ HMAC Signature لـ order.created والـ Authorization Token الممرر في الـ Header للتأكد من مطابقتها لمعايير سلة دون التسبب في حظر الطلبات الحقيقية.
إرسال طلب تجريبي (Payload) لتتبع تخزين الحدث في قاعدة البيانات بنجاح.
الالتزام المطلق بشروطك الصارمة: أخذ نسخة احتياطية (Backup) فورية من أي ملف قبل لمسه. عدم إعادة توليد (Regenerate) مفاتيح التطبيق نهائياً في Salla Partners للحفاظ على ربط التجار الحاليين. إعادة ضبط بيئة الإنتاج (LOG_LEVEL=error) وتنظيف الكاش بالكامل عبر Artisan فور الانتهاء.
مخرجات معيار قبول التسليم: فتح التطبيق بسلاسة من لوحة سلة والدخول الفوري دون خطأ 403.
سجلات قاعدة البيانات تؤكد استقبال الـ Webhook بنجاح للطلب التجريبي.
السلام عليكم ورحمة الله وبركاته تواصل معي ومش هنختلف على السعر ان شاء الله وده رأي اخر عميل ليا كان طالب نفس طلب حضرتكhttps://khamsat.com/user/mohamed_fathi31/reviews
في منصات الفريلانس هتلاقي كتير بيقولولك خبرة واحترافية مش هضيع وقتك هقولك حاجة واحدة ايا كان اللي محتاجه هتعامل معاه بنفس الجدية اللي بتعامل بيها فشغلي انا
انت مش بتدور على حد يجرب في بيئة الإنتاج بتاعتك انت بتدور على خبير يحل المشكلة فورا ولما قريت مشكلة الـ 403 Invalid Salla merchant وعرفت إن الطلب اليدوي بيرجع 200 عرفت إن المشكلة بنسبة كبيرة في الـ Sessions أو طريقة استلام وتوثيق الـ merchant_id جوة الـ iframe الخاص بسلة
انا خبير Laravel بقالي سنين واشتغلت مع 7 شركات من دول مختلفة وبنيت وحليت مشاكل أنظمة Embedded Apps وتكاملات OAuth كتير جدا عشان كده انا فاهم حساسية الشغل على بيئة الإنتاج (Production) و تقدر تشوف تقييماتي علي خمسات و مستقل اخر فتره https://mostaql.com/u/abdalm0rdy/reviews https://khamsat.com/user/yousef_mohamed0_0/reviews
ده اللي هيتم تنفيذه بالضبط ١ فحص وتصحيح مسار الـ OAuth واستقبال الـ merchant_id من سلة عشان نمنع خطأ 403 نهائيا لما التاجر يفتح التطبيق من تطبيقاتي ٢ اختبار الـ Webhook الخاص بـ order.created والتأكد من صحة التحقق من الـ HMAC وتسجيل الحدث فورا في قاعدة البيانات ٣ الالتزام التام بشروطك مفيش تجديد لأي مفاتيح في Salla Partners مفيش تعديل برة النطاق وهاخد نسخة احتياطية من أي ملف قبل تعديله ٤ تنظيف الكاش الخاص بـ Laravel وإرجاع LOG_LEVEL=error وتسليمك تقرير مختصر ومباشر بكل ملف اتعدل والسبب
بخصوص سابقة الأعمال مع سلة اشتغلت بالفعل على Salla Partners API وتطبيقات سلة المدمجة وعندي خبرة فعلية في التعامل مع دورة حياة الـ Webhooks والتحقق من الـ Signatures الخاصة بيها
مش هقولك هخلص بعد ايام لو اشتغلنا هكلمك بوضوح وموجود معاك لحد ما تفتح التطبيق وتتأكد ان الـ 403 اختفى والـ Webhooks بتسمع صح
خطأ 403 Invalid Salla merchant في Embedded Apps ده في الغالب مشكلة في التحقق من merchant_id وقت الـ OAuth handshake أو في middleware التحقق وده بالظبط اللي هشوفه أول حاجة
اشتغلت قبل كده على تطبيقات سلة مدمجة بنفس التركيبة دي من OAuth وWebhooks وPartners API وعارف كويس إزاي بيتعامل Laravel مع الـ token validation في بيئة الإنتاج
هشتغل بالضبط على نطاق المشكلة من تشخيص سبب الـ 403 والتأكد إن merchant_id بيوصل صح واختبار Webhook عبر order.created والتأكد من تسجيله في قاعدة البيانات وبعدين إعادة LOG_LEVEL لـ error وتنظيف الكاش وتسليم تقرير كامل بكل التعديلات وأسبابها من غير أي لمسة خارج نطاق المشكلة
تحت أمرك وجاهز أبدأ فور الاتفاق وتوفير بيانات الوصول
بصفتي خريجة كلية الحاسبات والذكاء الاصطناعي وبدرس حاليًا ماجستير في علوم الحاسب فأنا عارفه أن المشكلات دي غالبًا بتكون مرتبطة بآلية التحقق (Authentication)، أو تمرير بيانات التاجر، أو إعدادات الـ OAuth أثناء تشغيل التطبيق من داخل المنصة.
هبدأ أولًا بتشخيص سبب ظهور الخطأ دون إجراء أي تعديلات غير ضرورية ثم إصلاح المشكلة مع الحفاظ على استقرار بيئة الإنتاج والالتزام بالشروط اللي ذكرتها.
اللي هقدمه: • تشخيص السبب الحقيقي لخطأ 403. • مراجعة تدفق Authentication و`merchant_id`. • اختبار Webhooks والتأكد من استقبال `order.created`. • تنظيف Cache وإعادة إعدادات `LOG_LEVEL` بعد الانتهاء. • تسليم تقرير مختصر يوضح سبب المشكلة، والتعديلات التي تمت، وأسبابها.
قبل البدايه هراجع المشروع بالكامل وأشاركك بخطة العمل ومش هقوم بأي تعديل خارج نطاق المطلوب إلا بعد الرجوع إليك. يسعدني مناقشة التفاصيل والبدء مباشرة.
اطلعت على تفاصيل المشكلة، ويبدو أنها تتعلق بآلية OAuth / Merchant Context الخاصة بتطبيقات Salla Embedded Apps، وليس مجرد خطأ في Laravel نفسه.
لدي خبرة في Laravel والتعامل مع REST APIs، OAuth، Webhooks، والتكامل مع منصات التجارة الإلكترونية، ويمكنني تشخيص المشكلة بدقة دون إجراء أي تعديلات خارج نطاق المطلوب.
خطة العمل ستكون كالتالي:
أخذ نسخة احتياطية من الملفات قبل أي تعديل.
تتبع مسار إطلاق التطبيق من داخل لوحة "تطبيقاتي" حتى الوصول إلى سبب ظهور 403 Invalid Salla merchant.
مراجعة آلية استقبال والتحقق من merchant_id والتأكد من التعامل الصحيح مع بيانات الإطلاق القادمة من سلة.
مراجعة Middleware، Routes، Sessions، وAuthentication الخاصة بالتطبيق.
اختبار Webhooks وإنشاء طلب تجريبي للتأكد من استقبال حدث order.created وتسجيله داخل قاعدة البيانات.
بعد الانتهاء:
إعادة LOG_LEVEL=error. تنظيف Cache الخاص بـ Laravel. تسليم تقرير يوضح سبب المشكلة، والملفات المعدلة، وسبب كل تعديل.
سألتزم بعدم إعادة إنشاء مفاتيح التطبيق أو إجراء أي تعديل خارج نطاق المشكلة إلا بعد الرجوع إليكم، مع الحرص على أن يكون العمل مباشرة على بيئة الإنتاج بأمان.
يسعدني مناقشة التفاصيل والبدء فور توفير بيانات الوصول اللازمة.
اطلعت على تفاصيل المشكلة بالكامل، وبما أن الطلب اليدوي باستخدام merchant_id الصحيح يعمل ويُرجع 200 OK بينما يظهر الخطأ فقط عند فتح التطبيق من داخل "تطبيقاتي" في سلة، فهذا يشير إلى أن المشكلة غالبًا مرتبطة بمسار الإطلاق الخاص بالـ Embedded App نفسه، سواء أثناء التحقق من الـ Merchant Context أو أثناء تمرير بيانات التاجر داخل دورة تشغيل التطبيق من سلة.
سأتعامل مع المشكلة كعملية تشخيص وإصلاح Production Issue وليس كتطوير ميزة جديدة، لذلك ستكون خطوات العمل كالتالي:
أخذ نسخة احتياطية من أي ملف قبل إجراء أي تعديل. تتبع دورة تشغيل التطبيق بداية من إطلاقه من لوحة سلة وحتى نقطة ظهور الخطأ 403. مراجعة آلية استقبال والتحقق من merchant_id وبيانات التاجر القادمة من سلة. مراجعة Middleware و OAuth Flow وآلية حفظ واسترجاع بيانات التاجر داخل التطبيق. مراجعة إعدادات الـ Session والـ Cookies الخاصة بالتطبيق المضمن داخل لوحة سلة إذا كانت ضمن أسباب المشكلة. اختبار Webhook فعليًا عبر إنشاء طلب تجريبي والتأكد من استقبال حدث order.created وتسجيله داخل قاعدة البيانات. إعادة LOG_LEVEL=error وتنظيف Cache بعد الانتهاء من العمل. تسليم تقرير مختصر يوضح سبب المشكلة الحقيقي، والملفات التي تم تعديلها، والهدف من كل تعديل تم تنفيذه.
كما ألتزم بالكامل بالشروط المذكورة:
عدم إعادة توليد مفاتيح التطبيق داخل Salla Partners. عدم إجراء أي تعديلات خارج نطاق المشكلة دون الرجوع إليكم. العمل مباشرة على بيئة الإنتاج بأقصى درجات الحذر مع إمكانية التراجع عن أي تعديل عند الحاجة.
لدي خبرة في Laravel والتعامل مع OAuth و Webhooks والتكاملات الخارجية، وأتفهم جيدًا حساسية تطبيقات Embedded Apps واختلاف سلوكها عن الطلبات التقليدية أو الاختبارات اليدوية.
الهدف بالنسبة لي ليس فقط اختفاء رسالة 403 Invalid Salla merchant، وإنما التأكد من أن التطبيق يعمل بشكل طبيعي ومستقر عند التشغيل الحقيقي من داخل لوحة سلة مع نجاح دورة العمل بالكامل حتى استقبال الـ Webhooks وتسجيلها.
لاحظت أنك شخص محدد جدًا في المطلوب وعارف أين المشكلة لذلك لن أتكلم عن Laravel أو OAuth لأن هذا ليس ما تبحث عنه الآن
بما أن الطلب اليدوي يعمل ويرجع 200 فهذا يعني أن المشكلة ليست في التطبيق بالكامل وإنما في مسار تشغيل التطبيق من داخل سلة وهذا بالضبط ما سأبدأ به حتى أصل لسبب ظهور 403 وأعالجه من جذوره بدون أي تعديل خارج نطاق العمل وبدون المساس بمفاتيح التطبيق أو استقرار بيئة الإنتاج
سأختبر تشغيل التطبيق من تطبيقاتي ثم أتأكد من تمرير merchant_id والتحقق منه ثم أراجع دورة التشغيل كاملة حتى أضمن اختفاء الخطأ نهائيًا وبعدها سأختبر Webhook الخاص بـ order.created وأتأكد من تسجيله في قاعدة البيانات ثم أعيد إعدادات الإنتاج كما كانت مع تقرير واضح بكل تعديل تم ولماذا تم
أقدر حرصك على العمل مع شخص لديه خبرة فعلية وليس للتجربة لذلك سأتعامل مع مشروعك بنفس الطريقة التي أتعامل بها مع مشاريع العملاء التي تعمل على بيئة الإنتاج ولا أقوم بأي تعديل قبل أخذ نسخة احتياطية
أستطيع البدء مباشرة وإنهاء العمل خلال يوم واحد مقابل 60 دولار
نصيحة أخوية، هل قمت فحص أمني قبل العمل أو تأمين خادم الموقع؟ أكبر خطأ يقع فيه المستقلون هو إعداد دون تأمين , الخطوة الأولى والأهم بعد التطوير موقع الخاص بك هي فحصه للبحث عن الثغرات الأمنية وهذه هي وظيفتي .بصفتي باحثاً أمنياً ومختبر اختراق (Pentester) مصنفاً ضمن أفضل 4% عالمياً في TryHackMe، وخبيراً في فحص وأمن الـ APIs، عرضي لك لضمان استقرار أرباح عملائك وحماية أصولك الرقمية: الخدمة : اختبار الاختراق الشامل
OAuth Flow Security: فحص الـ Redirect URIs وإعدادات الـ Apps على منصات المطورين Burp Suite للتأكد من استحالة اختطاف الـ Access Tokens (Token Hijacking).
OWASP Top 10 & API Security: فحص قنوات الاتصال بالكامل ونقاط الربط ضد ثغرات OWASP الشائعة مثل الـ XSS، وحقن قواعد البيانات، وتجاوز الصلاحيات (IDOR/BOLA) عبر Postman.
Leak Data & Credentials Prevention: اختبار الأنظمة للتأكد من استحالة تسريب الـ Tokens الحساسة، وملفات الـ Service Account JSON، أو الـ App Secrets في الـ Client-side أو ملفات الـ JS المكشوفة.
Leak Files & Subdomains Recon: استخدام تقنيات البحث المتقدم وفحص الدومينات الفرعية (Subdomains) للتأكد من عدم وجود ملفات حساسة مسربة (مثل ملفات .env أو سجلات أخطاء مكشوفة) قد تكشف مفاتيح الربط للهكرز.
Business Logic Vulns: مراجعة منطق عمل المنظومة لضمان عدم وجود أي ثغرات برمجية تمكن المهاجم من التلاعب بالطلبات أو استهلاك الـ APIs بشكل غير مصرح به.
والمزيد من الأشياء.....تحقق من خدمتي لمزيد من المعلومات
السلام عليكم ورحمة الله. خطأ 403 Invalid Salla merchant في التطبيقات المدمجة (Embedded) غالباً ما ينتج عن خلل في التحقق من الـ App Signature أو الـ Authorization Header أثناء عمل الـ Custom Middleware المسؤولة عن فك تشفير البيانات القادمة من سلة (Iframe Validation)، أو بسبب إسقاط السيرفر (Hostinger) لـ Authorization Headers في البيئة الحية.
بصفتي مبرمج Full-Stack وخبير في تطوير أنظمة Laravel، لدي خبرة فعلية في بناء وربط تطبيقات سلة المدمجة وإدارة الـ Salla Partners API والتعامل مع الـ OAuth و الـ Webhooks وتأمينها عبر الـ HMAC. سأقوم بتشخيص وحل المشكلة على بيئة الإنتاج بأمان تام مع الالتزام التام بعدم توليد مفاتيح جديدة، واختبار وصول الـ Webhooks لتسجيل order.created بدقة، وصولاً لتنظيف الكاش وإعادة ضبط بيئة النظام وتسليم التقرير التقني المطلوب. يمكنك مراجعة تقييمات عملائي السابقة هنا في المنصة للتأكد من جودة واستقرار الحلول البرمجية التي أقدمها للبزنس.
هل المشكلة تظهر مع جميع التجار أم عند أول عملية ربط للتطبيق وتحديث الـ Access Token فقط؟
اطلعت على تفاصيل المشروع، وفهمت أن المطلوب هو تشخيص السبب الحقيقي لظهور خطأ **403 - Invalid Salla merchant** وإصلاحه دون إجراء أي تعديلات خارج نطاق المشكلة.
يمكنني مراجعة مشروع Laravel بالكامل، وتشخيص مسار تشغيل التطبيق من داخل سلة، وفحص التحقق من `merchant_id`، وآلية OAuth وWebhooks، ثم اختبار استقبال حدث `order.created` والتأكد من تسجيله في قاعدة البيانات.
كما سألتزم بأخذ نسخة احتياطية قبل أي تعديل، وإعادة `LOG_LEVEL=error` وتنظيف الكاش بعد الانتهاء، مع تسليم تقرير مختصر يوضح سبب المشكلة والملفات التي تم تعديلها.
مدة التنفيذ: يوم إلى يومين. السعر: 30 دولار.
معرض أعمالي: https://elgold-studio.vercel.app/ar
إذا توفرت بيانات الوصول، يمكنني البدء مباشرة في التشخيص وإصلاح المشكلة بأقل قدر ممكن من التعديلات.
مساء الخير، واضح إن المشكلة عندك مش في Laravel نفسه قد ما هي في الـ flow الحقيقي لفتح الـ Embedded App من داخل سلة، خصوصًا مع خطأ 403 Invalid Salla merchant رغم إن الطلب اليدوي بالـ merchant_id بيرجع 200. ده نوع الشغل اللي بشتغل عليه بشكل مريح: تشخيص السبب من جذوره، مراجعة التحقق من `merchant_id` ومسار الإطلاق من "تطبيقاتي"، والتأكد كمان إن Webhook زي `order.created` بيتسجل بشكل سليم من غير حلول مؤقتة. يهمني جدًا إن الإصلاح يطلع clean وكوده يفضل واضح وسهل تكمّل عليه بعدين، مع الالتزام الكامل بعدم الخروج عن نطاق المشكلة. تقدر تشوف نماذج من شغلي هنا https://mostaql.com/u/abdullah_tamim/portfolio ولو حابب نبدأ أراجع معاك نقطة الإطلاق والتحقق خطوة بخطوة ونوصل لسبب الخطأ بشكل واضح.
السلام عليكم أستاذ سفر، الشغل ده في مجالي بالظبط. بشتغل Laravel من 8 سنين وليا خبرة مع تطبيقات سلة المدمجة (OAuth / Partners API / Webhooks).
خطأ 403 Invalid Salla merchant اللي بيطلع عند الفتح من "تطبيقاتي" رغم إن الطلب اليدوي بنفس merchant_id بيرجّع 200، غالبا سببه إن مسار التحقق وقت الـ embedded launch مش هو نفس مسار الطلب اليدوي. سلة بتبعت هوية التاجر في سياق الإطلاق (توكن أو توقيع في الـ query أو الهيدر) والتطبيق بيتحقق منها بشكل مختلف، أو الـ access token المخزّن للتاجر يكون منتهي أو مربوط بـ merchant تاني غير اللي بيفتح، أو التحقق من الـ HMAC بيترفض عشان الـ payload اختلف.
طريقتي: أطلّع أثر الطلب من الـ logs في لحظة الـ 403، أقارن الـ merchant_id والتوكن الجايين من سلة وقتها بالمخزّن، أظبط نقطة التحقق، وأتأكد إن order.created webhook بيوصل ويتسجّل في الداتابيز بطلب تجريبي. بعدها أرجّع LOG_LEVEL=error وأنضّف الكاش وأبعتلك تقرير بالسبب والملفات اللي اتعدّلت وسبب كل تعديل. مش هلمس مفاتيح Salla Partners، وباخد باك أب لأي ملف قبل ما أعدّله، وشغلي في نطاق المشكلة بس.
المدة يوم لـ يومين بعد ما يوصّلي وصول hPanel/SSH ولوحة الشريك. التكلفة من 40$. جاهز أبدأ فور ما نتفق.
نصيحة أخوية، هل قمت فحص أمني قبل العمل أو تأمين خادم الموقع؟ أكبر خطأ يقع فيه المستقلون هو إعداد دون تأمين , الخطوة الأولى والأهم بعد التطوير موقع الخاص بك هي فحصه للبحث عن الثغرات الأمنية وهذه هي وظيفتي .بصفتي باحثاً أمنياً ومختبر اختراق (Pentester) مصنفاً ضمن أفضل 4% عالمياً في TryHackMe، وخبيراً في فحص وأمن الـ APIs، عرضي لك لضمان استقرار أرباح عملائك وحماية أصولك الرقمية: الخدمة : اختبار الاختراق الشامل
OAuth Flow Security: فحص الـ Redirect URIs وإعدادات الـ Apps على منصات المطورين Burp Suite للتأكد من استحالة اختطاف الـ Access Tokens (Token Hijacking).
OWASP Top 10 & API Security: فحص قنوات الاتصال بالكامل ونقاط الربط ضد ثغرات OWASP الشائعة مثل الـ XSS، وحقن قواعد البيانات، وتجاوز الصلاحيات (IDOR/BOLA) عبر Postman.
Leak Data & Credentials Prevention: اختبار الأنظمة للتأكد من استحالة تسريب الـ Tokens الحساسة، وملفات الـ Service Account JSON، أو الـ App Secrets في الـ Client-side أو ملفات الـ JS المكشوفة.
Leak Files & Subdomains Recon: استخدام تقنيات البحث المتقدم وفحص الدومينات الفرعية (Subdomains) للتأكد من عدم وجود ملفات حساسة مسربة (مثل ملفات .env أو سجلات أخطاء مكشوفة) قد تكشف مفاتيح الربط للهكرز.
Business Logic Vulns: مراجعة منطق عمل المنظومة لضمان عدم وجود أي ثغرات برمجية تمكن المهاجم من التلاعب بالطلبات أو استهلاك الـ APIs بشكل غير مصرح به.
والمزيد من الأشياء.....تحقق من خدمتي لمزيد من المعلومات
اطلعت على تفاصيل المشروع، ويمكنني تشخيص سبب ظهور خطأ **403 - Invalid Salla merchant** وإصلاحه مع الالتزام بعدم إجراء أي تعديلات خارج نطاق المشكلة.
سأقوم بمراجعة مشروع Laravel بالكامل، والتحقق من آلية تشغيل التطبيق من داخل لوحة سلة، ومراجعة التحقق من `merchant_id`، ومسار OAuth وWebhooks، ثم اختبار استقبال حدث `order.created` والتأكد من تسجيله في قاعدة البيانات.
كما سألتزم بأخذ نسخة احتياطية قبل أي تعديل، وإعادة `LOG_LEVEL=error` وتنظيف Cache بعد الانتهاء، مع تسليم تقرير يوضح سبب المشكلة، والملفات التي تم تعديلها، وسبب كل تعديل.
مدة التنفيذ: يوم إلى يومين. السعر: 30 دولار.
لدي خبرة قوية في Laravel، والتعامل مع REST APIs وOAuth وWebhooks، ويمكنني تشخيص المشكلات البرمجية والوصول إلى سببها بشكل منهجي.