تاریخچه فعالیت
چه کسی چه چیزی را تغییر داد، همراه مقادیر قبل و بعد — که فقط چون هر فرد ورود خودش را دارد قابلخواندن است.
باز کردن این موضوعراهنمای CDN.com.tr
نقشهای تیم: viewer، editor و owner
به هر همکار ورود جداگانه خودش و کوچکترین نقشی که کارش را ممکن میکند بدهید. همان نقش روی API هم اعمال میشود، پس یک bearer token هرگز نمیتواند بیش از فردی که به او تعلق دارد کاری انجام دهد.
سازمان، دسترسیها، پشتیبانی
نقشهای تیم: viewer، editor و owner
به هر همکار ورود جداگانه خودش و کوچکترین نقشی که کارش را ممکن میکند بدهید. همان نقش روی API هم اعمال میشود، پس یک bearer token هرگز نمیتواند بیش از فردی که به او تعلق دارد کاری انجام دهد.
مسیر در پنل
- Management Panel
- Authorization
- Create New User
- Role
پیشنیازها
- فقط مالک حساب میتواند زیرکاربر بسازد و نقش تعیین کند.
- هر فرد به آدرس ایمیل خودش نیاز دارد؛ اگر دو نفر یکی را به اشتراک بگذارند، ردپای ممیزی هیچ ارزشی ندارد.
- پیش از ساختن کاربر، نقش را تعیین کنید — این کار سادهتر از توضیح دادن یک شکاف مجوز بعداً است.
مدل تصمیمگیری
این فرد به کدام نقش نیاز دارد؟
بر اساس کوچکترین چیزی که او را از بنبست خارج میکند انتخاب کنید، نه بر اساس ارشدیت.
- Viewer: گزارشگیری، مانیتورینگ، آژانسی که فقط ارقام مصرف و کش را میخواند.
- Editor: توسعهدهنده یا ناشری که بعد از یک deploy purge میکند، delivery rules را ویرایش میکند و DNS و گواهیها را مدیریت میکند.
- Owner: شما، و هر کسی که به او در مورد صورتحساب و افزودن کاربران دیگر اعتماد دارید.
یک ورود یا یکی برای هر نفر؟
این انتخاب تعیین میکند که آیا audit log اصلاً میتواند به یک سؤال پاسخ بدهد یا نه.
- یک ورود برای هر نفر: هر ردیف در Activity history یک انسان واقعی را نام میبرد.
- یک ورود مشترک: هر اقدام یکسان بهنظر میرسد، و حذف یک نفر یعنی تغییر رمز عبور برای همه.
راهنمای گامبهگام
ساختن کاربر
Authorization صفحهای است که مالک زیرکاربران کل مشتری است، نه بهازای هر حساب.
- Authorization را باز کنید و روی Create New User کلیک کنید.
- نام، نام خانوادگی، ایمیل، تلفن و رمز عبور را دو بار پر کنید.
- هنوز ثبت نکنید — فهرست نقشها پایین همان فرم است.
نتیجه مورد انتظار: فرم کاربر جدید پر شده و جدول نقش زیر فیلدهای رمز عبور دیده میشود.
معادل cdnctl
POST /api/subusersتنظیم نقش
جدول نقش، نقشها را با یک کلید غیرفعال/فعال روی هرکدام فهرست میکند. آن نقشی که فرد نیاز دارد را روشن کنید.
- برای کسی که فقط گزارشها را میخواند، Viewer (read-only) را روشن کنید.
- برای کسی که purge میکند، یا delivery rules، DNS یا گواهیها را ویرایش میکند، Editor را روشن کنید.
- فقط زمانی همهچیز را خاموش بگذارید که یک viewer میخواهید — این چیزی است که یک نقش خالی به آن برمیگردد.
- روی Create User کلیک کنید.
نتیجه مورد انتظار: کاربر دقیقاً با نقشی که انتخاب کردید ساخته میشود، و میتواند با اطلاعات ورود خودش وارد شود.
معادل cdnctl
GET /api/rolesتأیید کنید مرز پابرجاست
از حساب جدید تأیید کنید، نه از حساب خودتان. این یک بررسی دودقیقهای است که از یک غافلگیری بد جلوگیری میکند.
- از فرد بخواهید وارد شود و صفحاتی که نیاز دارد را باز کند.
- از یک viewer بخواهید چیزی را ذخیره کند و تأیید کنید رد میشود.
- Activity history را باز کنید و تأیید کنید اقدامات او زیر نام خودش ثبت شده.
نتیجه مورد انتظار: فرد میتواند کارش را انجام دهد، از هر چیز دیگری مسدود است، و هر اقدامی که انجام میدهد قابلانتساب است.
معادل cdnctl
GET /api/accounts/<account_uuid>/activities?per_page=25راستیآزمایی
- یک viewer میتواند هر صفحه را باز کند اما نمیتواند چیزی جز پروفایل و رمز عبور خودش را ذخیره کند.
- یک editor میتواند purge کند و delivery rules را ویرایش کند اما هیچ اقدام زیرکاربر یا صورتحسابی ندارد.
- یک token صادرشده برای یک زیرکاربر روی نقاط پایانیای که نقش او پوشش نمیدهد رد میشود.
- Activity history بعد از تغییری که آنها اعمال میکنند، نام زیرکاربر را میآورد، نه مالک را.
موارد کاربرد
دو یا سه نفر روی یک حساب CDN کار میکنند: یکی منتشر میکند و باید purge کند، یکی فقط گزارشها را میخواند، و فقط شما باید بتوانید کاربر اضافه کنید یا به صورتحساب دست بزنید. یک رمز عبور مشترک به هر سه قدرت یکسان میدهد و audit log را بیفایده میکند.
جریان کاری سریع
- Authorization را باز کنید و بهجای اشتراک یک ورود، برای هر فرد یک کاربر بسازید.
- نقش را روی کاربر جدید تنظیم کنید: viewer برای فقط-خواندنی، editor برای عملیات روزمره، owner برای کنترل کامل.
- از فرد بخواهید وارد شود و تأیید کنید میتواند کارش را انجام دهد و نه چیزی فراتر از آن.
- بعداً Activity history را بررسی کنید: اقدامات آنها اکنون زیر نام خودشان ظاهر میشود.
بررسیها
- Viewer: هر صفحه را میخواند، و میتواند پروفایل و رمز عبور خودش را تغییر دهد. هیچ نوشتن دیگری.
- Editor: purge، delivery rules، DNS، گواهیها و ناممیزبانها. بدون مدیریت زیرکاربر، بدون صورتحساب، بدون حذف حساب.
- Owner: همهچیز، از جمله کاربران و صورتحساب. این همان نقشی است که حساب با آن ثبتنام شده.
- خالی گذاشتن نقش کاربر را viewer میکند. یک کاربر جدید هرگز با قدرتی بیش از آنچه اعطا کردهاید ساخته نمیشود.
- API همان قواعد را اعمال میکند. یک token از نوع viewer نمیتواند بنویسد، و یک token از نوع editor روی نقاط پایانی مخصوص owner رد میشود.