Genel bir MCP sunucusunu Odoo'nun çok kiracılı bir SaaS kurulumunda denediyseniz, muhtemelen tanıdık bir hata görmüşsünüzdür: 'hiçbir veritabanı seçilmedi' veya benzeri. Bu tesadüf değildir — mevcut MCP sunucularının çoğu tek veritabanlı bir kurulum için yazılmıştır ve her zaman tam olarak bir Odoo'nun bir veritabanıyla yanıt verdiğini varsayar.
Sorunun kökü nedir?
Çok kiracılı Odoo kurulumu (dbfilter) veritabanını istek ana bilgisayar adından tanımlar — company-a.example.com «company-a» veritabanına gider, company-b.example.com ise başka bir veritabanına. MCP sunucusu bunu bilmez ve yalnızca «her zaman bir veritabanı vardır» varsayarsa, doğru header ulaşmadığında veya ana bilgisayar belirsiz olduğunda Odoo hangi veritabanını seçeceğini bilemez ve hata verir — ya da daha kötüsü yanlış veritabanını seçer.
Doğru çözüm: forwarded host başlığından tanıma
MCP sunucusu, Odoo'nun dbfilter için kullandığı mantığı izlemelidir: isteğin gerçek ana bilgisayar adını (bir ters proxy arkasındaki X-Forwarded-Host başlığından) okumalı ve çalışma alanını buna göre belirlemelidir — sabit bir veritabanı varsaymamalıdır. Proxy başlığı değiştirirse veya başlık kaybolursa, bu sessiz bir başarısızlık olarak değil, hata yanıtında hemen belirtilmelidir.
İstek yanlış bir düğüme ulaştığında ne yapılmalıdır?
Çok düğümlü bir mimaride, bir istemci isteği istenen veritabanına hizmet vermeyen bir düğüme ulaşabilir. Doğru davranış, hata mesajında belirli bir durum kodu (örneğin 421 Misdirected Request) ve doğru çalışma alanı adresi vermektir — yanlışlıkla "bir şey bulunamadı" şeklinde yorumlanan boş yanıt değil, kesinlikle yanlış veritabanına hizmet vermek de değil.
Bir anahtar neden asla başka bir veritabanına erişebilmemeli
Tamamlayıcı bir güvenlik ilkesi: İstemci istek yolunda açıkça bir veritabanı adı gönderse bile sunucu bunu yalnızca bir doğrulama olarak ele almalı, anahtar olarak değil — düğümün gerçekten sunduğu veritabanı istemcinin istediğiyle farklıysa istek reddedilir, sunucu başka bir veritabanına bağlanmaya çalışmaz. Bu, bir kiracının verilerinin başka bir kiracının anahtarıyla sızmasını önler.
Abrak'ta bu nasıl çözüldü?
سرور MCP ابرک از ابتدا برای چندمستأجری طراحی شده: فضای کاری از نام میزبان تشخیص داده می‌شود، مسیر صریح /mcp/<دیتابیس> فقط برای بررسی است نه سوییچ، و هر خطای مسیریابی نشانی درست را در پاسخ اعلام می‌کند. جزئیات فنی کامل و نحوه‌ی اتصال در MCP sunucusu uygulama sayfası ve Bağlantı eğitimi yer almaktadır.
سه الگوی اشتباه رایج در مسیریابی چندمستأجره
هر سه در نگاه اول کار می‌کنند و در تولید، زیر بار یا هنگام جابه‌جایی نود می‌شکنند.
| الگو | چرا وسوسه‌کننده است | کجا می‌شکند |
|---|---|---|
| نگهداری دیتابیس در حالت نشست | ساده و سریع | درخواست بعدی به نود دیگری می‌رسد و حالت نیست |
| حدس زدن مستأجر از روی کلید | کلید که هست، پس کافی است | کلید دزدیده‌شده به هر دیتابیسی اشاره می‌کند |
| پیش‌فرض گرفتن «آخرین دیتابیس» | در محیط تک‌مستأجرِ توسعه درست کار می‌کند | در تولید، داده‌ی مستأجر اشتباه برمی‌گردد |
چک‌لیست پیش از تولید برای یک سرور MCP چندمستأجره
- هر درخواست خودکفا باشد: مستأجر از خودِ درخواست تعیین شود، نه از حافظه‌ی سرور. سرور باید بتواند بی‌حالت باشد.
- کلید به مستأجر گره بخورد: کلید فقط برای یک دیتابیس معتبر باشد؛ اگر درخواست به دیتابیس دیگری اشاره کرد، رد شود — نه اینکه به دیتابیس کلید هدایت شود.
- خطای صریح به‌جای پیش‌فرض: اگر مستأجر قابل تشخیص نبود، پاسخ باید خطا باشد. هر پیش‌فرضی اینجا یعنی نشت داده.
- لاگ با شناسهٔ مستأجر: بدون آن، اشکال‌یابی نشت داده بین مستأجرها عملاً ممکن نیست.
- تست با دو مستأجر هم‌زمان: بیشتر باگ‌های این دسته با یک مستأجر هرگز ظاهر نمی‌شوند.
چرا این موضوع فقط مسئلهٔ مهندسی نیست
نشت داده بین دو مستأجر، برخلاف یک خطای معمول، برگشت‌پذیر نیست: داده‌ای که یک مشتری دیده، دیده است. به همین دلیل معیار درست «آیا کار می‌کند» نیست، «آیا می‌تواند به دیتابیس اشتباه برسد» است — و پاسخ باید معماری‌محور باشد، نه مبتنی بر دقت کد. تحلیل عمیق‌تر جداسازی در انزوای داده در سرور MCP چندمستأجر و کنترل‌های کلید در چک‌لیست امنیتی کلیدهای MCP آمده است. پیاده‌سازی آمادهٔ ابرک در صفحهٔ MCP برای اودوو.
