إذا جرّبت خادم MCP عامًا على تثبيت SaaS متعدد المستأجرين لأودو، فمن المرجح أنك رأيت خطأً مألوفًا: «لم يُحدَّد قاعدة بيانات» أو ما شابه. هذا ليس عشوائيًا — فمعظم خوادم MCP المتاحة كُتبت لتثبيت بقاعدة بيانات واحدة، وتفترض دائمًا وجود أودو واحد بقاعدة بيانات واحدة فقط يستجيب.
ما أصل المشكلة؟
يتعرّف التثبيت متعدد المستأجرين في Odoo (dbfilter) على قاعدة البيانات من اسم المضيف في الطلب — فـ company-a.example.com يذهب إلى قاعدة البيانات «company-a» وcompany-b.example.com إلى قاعدة أخرى. فإن لم يعرف خادم MCP هذا وافترض أن «هناك دائمًا قاعدة بيانات واحدة»، فعندما لا تصل الترويسة الصحيحة أو يكون المضيف ملتبسًا، لا يعرف Odoo أي قاعدة بيانات يختار فيعطي خطأ — أو الأسوأ، يختار قاعدة البيانات الخطأ.
الحل الصحيح: الكشف من ترويسة المضيف المُمرَّر (forwarded host)
يجب أن يتبع خادم MCP المنطق نفسه الذي يستخدمه Odoo ذاته لـ dbfilter: أن يقرأ اسم المضيف الفعلي للطلب (من ترويسة X-Forwarded-Host خلف reverse proxy) ويحدد مساحة العمل بناءً عليه، لا أن يفترض قاعدة بيانات ثابتة. وإن غيّر الوكيل الترويسة أو فُقدت وجب أن يتضح ذلك فورًا في استجابة الخطأ، لا أن يكون فشلًا صامتًا.
ماذا يجب أن يحدث عندما يصل الطلب إلى العقدة الخطأ؟
في بنية متعددة العقد قد يرسل عميل طلبًا يصل إلى عقدة لا تخدم قاعدة البيانات المطلوبة. السلوك الصحيح هو رمز حالة محدد (مثل 421 Misdirected Request) مع عنوان مساحة العمل الصحيح في رسالة الخطأ، لا استجابة فارغة تُفسَّر خطأً بأنها «لم يُعثر على شيء»، وبالتأكيد لا خدمة قاعدة بيانات خاطئة.
لماذا يجب ألا يتمكن المفتاح أبداً من الوصول إلى قاعدة بيانات أخرى
مبدأ أمني مكمِّل: حتى لو أرسل العميل صراحةً اسم قاعدة بيانات في مسار الطلب، يجب أن يتعامل الخادم معه كـتحقق فقط لا كـتبديل — فإذا اختلفت قاعدة البيانات التي تخدمها العقدة فعليًا عمّا طلبه العميل، يُرفض الطلب بدلًا من أن يحاول الخادم الاتصال بقاعدة بيانات أخرى. هذا يمنع تسرّب بيانات مستأجر إلى مفتاح مستأجر آخر.
كيف حُلّ هذا في Abrak؟
سرور MCP ابرک از ابتدا برای چندمستأجری طراحی شده: فضای کاری از نام میزبان تشخیص داده می‌شود، مسیر صریح /mcp/<دیتابیس> فقط برای بررسی است نه سوییچ، و هر خطای مسیریابی نشانی درست را در پاسخ اعلام می‌کند. جزئیات فنی کامل و نحوه‌ی اتصال در صفحة تطبيق خادم MCP و دليل الاتصال وارد.
سه الگوی اشتباه رایج در مسیریابی چندمستأجره
هر سه در نگاه اول کار می‌کنند و در تولید، زیر بار یا هنگام جابه‌جایی نود می‌شکنند.
| الگو | چرا وسوسه‌کننده است | کجا می‌شکند |
|---|---|---|
| نگهداری دیتابیس در حالت نشست | ساده و سریع | درخواست بعدی به نود دیگری می‌رسد و حالت نیست |
| حدس زدن مستأجر از روی کلید | کلید که هست، پس کافی است | کلید دزدیده‌شده به هر دیتابیسی اشاره می‌کند |
| پیش‌فرض گرفتن «آخرین دیتابیس» | در محیط تک‌مستأجرِ توسعه درست کار می‌کند | در تولید، داده‌ی مستأجر اشتباه برمی‌گردد |
چک‌لیست پیش از تولید برای یک سرور MCP چندمستأجره
- هر درخواست خودکفا باشد: مستأجر از خودِ درخواست تعیین شود، نه از حافظه‌ی سرور. سرور باید بتواند بی‌حالت باشد.
- کلید به مستأجر گره بخورد: کلید فقط برای یک دیتابیس معتبر باشد؛ اگر درخواست به دیتابیس دیگری اشاره کرد، رد شود — نه اینکه به دیتابیس کلید هدایت شود.
- خطای صریح به‌جای پیش‌فرض: اگر مستأجر قابل تشخیص نبود، پاسخ باید خطا باشد. هر پیش‌فرضی اینجا یعنی نشت داده.
- لاگ با شناسهٔ مستأجر: بدون آن، اشکال‌یابی نشت داده بین مستأجرها عملاً ممکن نیست.
- تست با دو مستأجر هم‌زمان: بیشتر باگ‌های این دسته با یک مستأجر هرگز ظاهر نمی‌شوند.
چرا این موضوع فقط مسئلهٔ مهندسی نیست
نشت داده بین دو مستأجر، برخلاف یک خطای معمول، برگشت‌پذیر نیست: داده‌ای که یک مشتری دیده، دیده است. به همین دلیل معیار درست «آیا کار می‌کند» نیست، «آیا می‌تواند به دیتابیس اشتباه برسد» است — و پاسخ باید معماری‌محور باشد، نه مبتنی بر دقت کد. تحلیل عمیق‌تر جداسازی در انزوای داده در سرور MCP چندمستأجر و کنترل‌های کلید در چک‌لیست امنیتی کلیدهای MCP آمده است. پیاده‌سازی آمادهٔ ابرک در صفحهٔ MCP برای اودوو.
