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