حالت شکستِ خاموشِ یک یکپارچهسازیِ مشترک
بیشتر محصولات SaaS که با گوگل یکپارچه میشوند، یک اپ OAuth در سطح کل سرور ثبت میکنند، و هر فراخوانیِ تقویم یا درایوِ هر مشتری از میان همان میگذرد. این تا وقتی مصرف رشد کند خوب کار میکند — سهمیههای API گوگل بهازای هر اپ است، نه هر مشتری، پس یک سازمان که یک سینک غیرعادی پرحرف اجرا میکند میتواند به فضایی نفوذ کند که هر سازمان دیگر روی پلتفرم به آن وابسته است. هیچکس تا وقتی سینک تقویم یک تننت کاملاً بیربط به دلیلی که هیچ ربطی به کاری که کرده ندارد شروع به شکستخوردن نکند، متوجه نمیشود.
پاسخ ویکیافگو: اپ خودتان، سهمیهی خودتان
// Package orgcreds stores per-organization OAuth app credentials, so every
// tenant brings its own third-party app (its own Google Cloud project, …)
// instead of sharing one server-wide app from the environment. Org admins
// manage them in the UI (/integrations); integrations resolve credentials
// per-org at call time and fall back to the server env only when the org has
// none — self-hosted single-tenant installs keep working unchanged.
هر سازمان میتواند پروژهی گوگلکلاود خودش را ثبت کند و شناسهی کلاینت و رمزش را در Integrations در ویکیافگو وارد کند. از آن نقطه، هر فراخوانیِ تقویم و درایوی که آن سازمان انجام میدهد روی سهمیهی خودش اجرا میشود، زیر صورتحساب گوگلکلاود خودش اگر از ردهی رایگان فراتر برود — کاملاً ایزوله از هر سازمان دیگر روی همان نمونهی ویکیافگو.
چهچیزی ذخیره میشود، و چطور محافظت میشود
type OrgCredential struct {
OrganizationID uint
Provider string // "google" — تقویم و درایو را پوشش میدهد
ClientID string
ClientSecret string `json:"-"` // رمزنگاریشده
UpdatedBy uint
}
رمز کلاینت پیش از رسیدن به پایگاهداده، زیر یک کلیدِ اختصاصیشده به یک هدف (orgcreds) رمزنگاری میشود، و با json:"-" تگگذاری شده تا بعد از ذخیرهشدن هرگز در هیچ پاسخ APIای برنگردد — رابط کاربریای که مدیریتش میکند میتواند بهروزرسانیش کند، اما نمیتواند دوباره بخواندش. یک provider هم تقویم و هم درایو را پوشش میدهد چون گوگل صرفنظر از تعداد APIهایی که فعال میکنید، یک اپ OAuth بهازای هر پروژهی کلاود صادر میکند.
بازگشتی که self-hosting را ساده نگه میدارد
func Lookup(db *gorm.DB, orgID uint, provider string) (clientID, clientSecret string, ok bool) {
// اعتبارنامهی رمزگشاییشدهی سازمان را برمیگرداند؛ ok وقتی سازمان چیزی ندارد false است
}
اگر یک سازمان اپ خودش را ثبت نکرده باشد، Lookup مقدار ok = false برمیگرداند و کد فراخواننده به یک اعتبارنامهی سراسریِ سرور از محیط بازمیگردد. این یک راهحل نصفهونیمه نیست — طراحیِ عمدی برای حالت رایجِ self-hosted است: یک شرکت، یک نمونه، هیچ دلیلی برای اجباریِ یک اپ OAuth مخصوص هر سازمان وقتی «سازمان» و «خودِ استقرار» یک چیزند. استقرارهای ابریِ چندتننتی جایی است که اعتبارنامههای مخصوص هر سازمان واقعاً اهمیت پیدا میکنند، و دقیقاً همانجایی است که یک ادمین سازمان میرود تنظیمشان میکند.
راهاندازیِ پروژهی گوگلکلاود خودتان
۱. یک پروژهی گوگلکلاود بسازید (یا یکی که از قبل دارید را استفاده مجدد کنید) و Calendar API را فعال کنید.
۲. صفحهی رضایت OAuth را با اسم سازمانتان تنظیم کنید — این چیزی است که تیم خودتان روی پرامپت اجازهی گوگل میبیند، نه یک اسم اپِ ثالثِ عمومی.
۳. اعتبارنامههای OAuth 2.0 بسازید و آدرس بازگشتِ ویکیافگو را بهعنوان یک redirect مجاز اضافه کنید.
۴. شناسهی کلاینت و رمز را در Integrations در ویکیافگو وارد کنید. از اینجا، سینک تقویم گوگل از اپ شما استفاده میکند، نه یک اپ مشترک.
اشتباهات رایج
فرضکردن اینکه این برای استفاده از سینک تقویم اصلاً اجباری است. نیست — بازگشت به یک اعتبارنامهی سمتسرور دقیقاً برای همین وجود دارد که یک تیم کوچک برای امتحانکردن قابلیت لازم نباشد Google Cloud Console را لمس کند. ثبتِ اپ خودتان وقتی اهمیت پیدا میکند که مصرف یا نیازمندیهای مطابقت، یک سهمیهی مشترک یا یک هویتِ اپ مشترک را به یک مشکل تبدیل کنند.
محدودکردن صفحهی رضایت OAuth به فقط کاربران داخلی، بعد تعجب از اینکه چرا اتصال شکست میخورد. اگر صفحهی رضایت پروژهی کلاودتان روی «Internal» تنظیم باشد، فقط حسابهای داخل Google Workspace خودتان میتوانند تأییدش کنند — اگر آن همهی کاربران ویکیافگو باشد خوب است، اگر نباشد منبع شکستهای گیجکننده است.
چرخاندنِ رمز در گوگلکلاود بدون بهروزرسانیش در ویکیافگو. این دو باید با هم بهروزرسانی شوند؛ ویکیافگو هیچ راهی برای تشخیصِ چرخش رمز در سمت گوگل ندارد تا وقتی فراخوانی API بعدی شکست بخورد.
سؤالات متداول
این فراتر از اشتراک ویکیافگو هزینهای دارد؟ APIهای تقویم و درایو گوگل یک ردهی رایگانِ سخاوتمند دارند که بیشتر سازمانها هرگز از آن فراتر نمیروند؛ فقط زیر مصرف API غیرعادی سنگین صورتحساب گوگلکلاود میبینید.
آیا سازمانهای متفاوت روی همان نمونهی ویکیافگو میتوانند از دامنههای Google Workspace متفاوت استفاده کنند؟ بله — اپ OAuth هر سازمان کاملاً مستقل است، پس این دقیقاً همان موردی است که اعتبارنامههای مخصوص هر سازمان برایش ساخته شدهاند.
اگر از اپ بازگشتی به اپ خودم تغییر کنم، برای لینکهای تقویم موجود چه اتفاقی میافتد؟ لینکهای رویداد موجود همچنان کار میکنند؛ فراخوانیهای سینک جدید از اینجا به بعد سهمیهی اپ شما را استفاده میکنند.