تیم‌ها و دسترسی

ددقیقاً همان دسترسی مورد نیازی را که هر فرد در تیم شما به آن نیاز دارد، به او بدهید.

چهار نقش مشتری، زیرحساب‌هایی که بازتاب‌دهنده ساختار واقعی کسب‌وکار شما هستند، کلیدهای API مختص هر سازمان، ورود تک‌مرحله‌ای (SSO) و یک گزارش حسابرسی در پشت هر اقدام دارای دسترسی ویژه. همین مدل دسترسی در داشبورد، API، خط فرمان (CLI)، ترافورم (Terraform) و سرور MCP ما اجرا می‌شود. در دسترس بودن: ارائه‌دهنده ترافورم در حال توسعه فعال است و هنوز در دسترس نیست. هر چیز دیگری که در اینجا توصیف شده است، همین امروز فعال است.

  • +۶۵۰,۰۰۰سایت‌های میزبانی‌شده در سراسر جهان
  • ۴نقش‌های مشتری، از پیش‌آماده و آماده‌ی استفاده
  • ۳۵کلیدهای دسترسی دقیق
  • ۱۴ روزآزمایشی رایگان کارت

چهار نقش، ترسیم‌شده در جایی که کار واقعاً تقسیم می‌شود

دسترسی یک کلید ساده‌ی روشن/خاموش نیست. هر سازمان مشتری دارای چهار نقش است که هر کدام مجموعه‌ای ثابت از دسترسی‌های دقیق module.action هستند — بنابراین یک رابط مالی هرگز به سروری دست نمی‌زند و یک توسعه‌دهنده هرگز فاکتوری را نمی‌بیند.

مالک

کنترل کامل بر سازمان و زیرمجموعه‌های آن: ایجاد سازمان‌های فرعی، دعوت و حذف اعضا، تغییر نقش‌ها، مدیریت کلیدهای API، راه‌اندازی، راه‌اندازی مجدد، مسدود کردن و حذف وب‌سایت‌ها، مدیریت صورت‌حساب‌ها و روش‌های پرداخت، و مطالعه گزارش حسابرسی. دو مورد عمداً خارج از این محدوده قرار دارند — بستن سازمان و صدور بازپرداخت از اقدامات کادر پشتیبانی است، نه نقش مشتری.

مدیر امور مالی

تمام امور مالی و هیچ‌چیز دیگر: فاکتورها، اشتراک‌ها، روش‌های پرداخت و کاتالوگ پلن‌ها، به همراه نمای سازمان و فهرست اعضای آن. بدون هیچ‌گونه دسترسی به سایت — یک مسئول مالی یا حسابدار خارجی نمی‌تواند چیزی را مجدداً راه‌اندازی، معلق یا حذف کند.

برنامه‌نویس

روی سایت‌ها بدون دخالت در بخش مالی کار کنید: مشاهده و راه‌اندازی سایت‌ها، راه‌اندازی مجدد سرویس‌ها، پاکسازی کش‌ها، مدیریت کلیدهای API، و ایجاد یا پاسخ به تیکت‌های پشتیبانی. بدون دسترسی به صورتحساب، بدون مدیریت اعضا، بدون تعلیق و بدون حذف — اقدامات مخرب و تجاری در اختیار مالک باقی می‌ماند.

فقط‌خواندنی

یک نمای کامل بدون امکان تغییر هیچ‌چیز — اعضا، سایت‌ها، صورت‌حساب، پلن‌ها، تیکت‌ها، وضعیت ترجمه و لاگ حسابرسی. نقشی مناسب برای یک ذینفع مشتری، یک حسابرس داخلی یا نیروی تازه‌کاری که هنوز جای پای خود را پیدا نکرده است.

زیرحساب‌هایی که با ساختار واقعی شما مطابقت دارند

اجاره‌داری یک ساختار درختی است، نه یک فهرست مسطح. یک سازمان نمایندگی فروش در بالای سازمان‌های مشتری خود قرار می‌گیرد و سایت‌ها زیر آن‌ها قرار دارند. یک عضو تیم یک عضویت است — یک کاربر، یک سازمان، یک نقش — بنابراین همین مؤلفه پایه، یک تیم دو نفره، یک آژانس مدیریت‌کننده صد حساب مشتری و یک نماینده فروش را که زیر برند خود زیرحساب می‌داند، پشتیبانی می‌کند.

نقش‌ها برای هر سازمان به صورت جداگانه اعطا می‌شوند و اعمال آن‌ها نیز به ازای هر سازمان است. داشتن یک نقش در یک سازمان هیچ دسترسی‌ای در یک سازمان دیگر و نامرتبط اعطا نمی‌کند — یک پیمانکار می‌تواند با همان ورود به سیستم، در یک حساب کاربری مشتری نقش «توسعه‌دهنده» و در حساب دوم نقش «فقط خواندنی» داشته باشد. با این حال، دسترسی در هویراکی (سلسله‌مراتب) خود شما جریان پیدا می‌کند: یک نقش در سازمان والد برای سازمان‌های زیرمجموعه آن نیز اعمال می‌شود، که این همان روشی است که نمایندگان فروش و آژانس‌ها از طریق آن مشتریان خود را مدیریت می‌کنند.

انزوا در پایگاه داده اعمال می‌شود، نه فقط در کد برنامه. امنیت سطح ردیف پُست‌گرس، هر پرس‌وجوی مشتری را به زیردرخت فراخواننده محدود می‌کند، و هر چیزی خارج از آن زیردرخت به جای خطای دسترسی، نتیجه پیدا نشد را برمی‌گرداند — بنابراین پلتفرم حتی تایید نمی‌کند که سازمان یا سایت مشتری دیگری وجود دارد.

دسترسی‌های یکسان در تمام بخش‌ها

نقش‌ها صرفاً یک امکان راحت در داشبورد نیستند. هر راه ورودی به پلتفرم به همان کلیدهای دسترسی منتهی می‌شود، بنابراین هیچ در پشتی‌ای وجود ندارد که قوانین دسترسی شما را دور بزند.

داشبورد

سایت‌ها، صورت‌حساب، تیکت‌ها، اطلاعیه‌ها، اعلان‌ها، کلیدهای API و مدیریت تیم در یک محیط واحد. رابط کاربری آنچه را که نقش عضو واردشده اجازه می‌دهد نمایش می‌دهد، بنابراین کنترل‌هایی که افراد نمی‌توانند استفاده کنند به آن‌ها نشان داده نمی‌شود.

API عمومی و خط فرمان

API منتشرشده همان موتور API است که داشبورد استفاده می‌کند. کلیدهای API برای هر سازمان با محدوده‌های جزئی مرتبط با مجوزهای RBAC صادر می‌شوند و حالت‌های سندباکس و زنده مجزا به این معناست که می‌توانید یکپارچه‌سازی‌ها را بدون دست زدن به صورتحساب یا ارائه‌دهی واقعی آزمایش کنید.

ارائه‌دهنده Terraform

سایت‌ها، دامنه‌ها، DNS، صندوق‌های پستی و پلن‌ها را به عنوان زیرساخت‌به‌عنوان‌کد مدیریت کنید و terraform apply را برای تأمین هاستینگ اجرا کنید — که توسط همان محدوده‌های بقیه مدیریت می‌شود.

سرور MCP

Claude Code، Cursor، ChatGPT، Claude Desktop یا هر ابزار سازگار با MCP را متصل کنید. توکن‌ها به یک سازمان و مجوزهای RBAC آن محدود می‌شوند، برای هر ابزار قابل لغو هستند، با تأیید برای اقدامات مخرب، سقف هزینه‌ها و یک دنباله حسابرسی کامل.

مدیریت کلید

فقط هش هر کلید API ذخیره می‌شود — هرگز کلید اصلی ذخیره نمی‌شود. کلیدها دارای یک نام و یک پیشوند قابل‌مشاهده هستند تا بتوانید آن‌ها را از یکدیگر تشخیص دهید، زمان آخرین استفاده از آن‌ها را ثبت کنید، و بتوانید هر کدام را به طور جداگانه و بدون ایجاد اختلال در بقیه باطل کنید.

یک ورود، مبتنی بر استاندارد، در تمام بخش‌ها

هویت کاربران توسط Keycloak مدیریت می‌شود، بنابراین احراز هویت مبتنی بر استانداردهای واقعی OIDC و SAML است و نه یک فرم ورود سفارشی که به کنترل‌پنل میزبانی وب سنجاق شده باشد.

  • ورود پیش‌فرض با ایمیل جادویی (Magic-link)، همراه با ایمیل و رمز عبور به‌عنوان روش جایگزین برای کاربرانی که آن را ترجیح می‌دهند.
  • کلیدهای عبور و WebAuthn برای ورود مقاوم در برابر فیشینگ، به‌علاوه احراز هویت دو مرحله‌ای TOTP که توسط سیاست‌نامه برای همه الزامی شده است.
  • ورود اجتماعی از طریق Google، مایکروسافت، GitHub و سایر ارائه‌دهندگان هویت.
  • ورود تک‌مرحله‌ای SAML برای مشتریان سازمانی و آژانس‌ها، به‌طوری‌که دسترسی تیم از فهرست راهنمای موجود شما پیروی می‌کند.
  • یک نشست در سراسر داشبورد، کنسول مدیریت، سایت عمومی و پایگاه دانش، و تیکت‌های پشتیبانی؛ یک بار وارد شوید، نه پنج بار.
  • هر ایمیل ثبت‌نامی پیش از ایجاد حساب کاربری اعتبارسنجی می‌شود، بنابراین آدرس‌های نامعتبر و غیرقابل‌تحویل هرگز به تیم شما راه پیدا نمی‌کنند.
  • از آنجا که این راهکار مبتنی بر استانداردها است، خودِ ارائه‌دهنده هویت بدون نیاز به بازطراحی زیرساخت‌ها قابل جایگزینی است؛ همان قانون عدم وابستگی به فروشنده که در مورد سایر ارائه‌دهندگان نیز اعمال می‌کنیم.

مسولیت‌پذیری‌ای که می‌توانید به حسابرس تحویل دهید

هر عملیات دسترسی‌ویژه یک رکورد حسابرسی فقط‌افزودنی ثبت می‌کند: چه کسی آن را انجام داده، چه کاری انجام داده است، روی چه چیزی انجام شده، مستندات پشتیبان و آدرس IP مبدأ. این گزارش فقط‌افزودنی است — رویدادها اضافه می‌شوند، نه اینکه در جای خود ویرایش شوند — و در محیط پروداکشن بر اساس زمان پارتیشن‌بندی می‌شود تا با رشد حجم داده‌ها همچنان سریع بماند.

خواندن آن لاگ خود یک مجوز است. مالکان و اعضای فقط خواندنی آن را در اختیار دارند، بنابراین فرد مسئول حساب و فردی که آن را حسابرسی می‌کند، هر دو می‌توانند تاریخچه کامل را بدون نیاز به داشتن دسترسی‌های سطح بالا مشاهده کنند.

در پیرامون آن، کنترل‌هایی قرار دارند که تیم‌های بزرگ‌تر درخواست می‌کنند: خط‌مشی‌های نشست، فهرست‌های مجاز IP اختیاری برای هر سازمان، و احراز هویت مرحله‌ای برای اقدامات حساس تا یک نشست زنده به‌تنهایی برای انجام کاری جدی کافی نباشد.

چگونگی رشد دسترسی‌ها همگام با شما

کالوگ مجوزها داده است، نه منطق سخت‌کدشده — به همین دلیل است که می‌توان آن را بدون نیاز به لوله‌کشی مجدد پلتفرم توسعه داد.

  • امروز ۳۵ کلید دقیق module.action، شامل سازمان‌ها، اعضا، کلیدهای API، سایت‌ها، صورت‌حساب، پلن‌ها، ناوگان، تیکت‌ها، مشتریان، سوءاستفاده، کمپین‌ها، ترجمه‌ها و حسابرسی.
  • فهرست محصولات در هر بار استقرار به صورت هم‌پایدار (idempotent) بارگذاری می‌شود و اگر نقشی به دسترسی ناموجودی ارجاع دهد، اعتبارسنجی با صدای بلند شکست می‌خورد؛ بنابراین یک خطای تایپی نمی‌تواند به‌طور خاموش هیچ‌چیز را اعطا نکند.
  • قابلیت‌های جدید محصول، کلیدهای دسترسی خود را پیش از انتشار اندپوینت به کاتالوگ اضافه می‌کنند؛ بنابراین کنترل دسترسی هرگز پس از فعال‌سازی یک ویژگی، به‌صورت واکنشی اعمال نمی‌شود.
  • محدود کردن یک عضویت واحد به سایت‌های خاص یا یک منطقه خاص، یک بهینه‌سازی برنامه‌ریزی‌شده است، نه چیزی که امروز بتوانید آن را فعال کنید. الگوی فعلی این است که آن سایت‌ها را در یک سازمان فرعی قرار دهید و به آن شخص در آنجا نقشی اختصاص دهید — که همان تفکیک را با استفاده از درخت احاره‌داری (tenancy tree) به شما می‌دهد.
  • کلیدهای API در سطح سازمان و نه به‌صورت فردی صادر می‌شوند، بنابراین با آن‌ها مانند اعتبارنامه‌های سرویس برای ادغام‌ها رفتار کنید و از عضویت‌ها برای دسترسی انسانی استفاده کنید.

سوالات متداول

هر نقش دقیقا چه کاری می‌تواند انجام دهد؟

مالک کنترل کامل سازمان و زیرحساب‌های آن، از جمله اعضا، کلیدهای API، سایت‌ها و روش‌های پرداخت را دارد. مدیر صورت‌حساب، فاکتورها، اشتراک‌ها، روش‌های پرداخت و پلن‌ها را مشاهده می‌کند، بدون دسترسی به سایت. توسعه‌دهنده، سایت‌ها و کلیدهای API را مدیریت می‌کند و تیکت‌ها را رسیدگی می‌نماید، بدون کنترل صورت‌حساب یا اعضا. دسترسی فقط‌خواندنی می‌تواند اعضا، سایت‌ها، صورت‌حساب، پلن‌ها، تیکت‌ها و گزارش حسابرسی را بدون تغییر دادن چیزی مشاهده کند.

آیا می‌توانم به کسی فقط به یک وب‌سایت دسترسی بدهم؟

هنوز به صورت تنظیمات برای هر سایت موجود نیست — محدود کردن یک عضویت واحد به سایت‌های خاص، یک بهینه‌سازی برنامه‌ریزی‌شده است. امروزه می‌توانید همین تفکیک را با ساختار درختی سازمان انجام دهید: آن سایت‌ها را در یک سازمان فرزند قرار دهید و به فرد در آنجا یک نقش اختصاص دهید. از آنجا که نقش‌ها به ازای هر سازمان اعطا می‌شوند، این دسترسی به هیچ چیز دیگری در حساب شما منتقل نمی‌شود.

آیا کلیدهای API به اعضای فردی تیم مرتبط هستند؟

خیر — کلیدهای API برای هر سازمان صادر می‌شوند، با محدوده‌های جزئی مرتبط با همان دسترسی‌های RBAC و حالت‌های جداگانه سندباکس و زنده. از آن‌ها به عنوان اعتبارنامه‌های سرویس برای یکپارچه‌سازی‌ها، CI یا Terraform استفاده کنید و از عضویت‌ها برای افراد بهره ببرید. فقط هش هر کلید ذخیره می‌شود، تاریخ آخرین استفاده از هر کلید ثبت می‌شود و هر کلید را می‌توان به طور مستقل باطل کرد.

آیا یک توسعه‌دهنده می‌تواند تغییرات را روی یک سایت زنده (لایو) اعمال کند؟

نقش توسعه‌دهنده شامل مشاهده و راه‌اندازی سایت‌ها، راه‌اندازی مجدد سرویس‌ها، پاکسازی کش‌ها، مدیریت کلیدهای API و رسیدگی به تیکت‌ها است. این نقش دسترسی انتشار روی سایت زنده را ندارد، بنابراین اگر می‌خواهید شخصی توانایی انتشار تغییرات را داشته باشد، این دسترسی باید نزد یک مالک باشد. نقش‌ها مختص هر سازمان هستند، بنابراین می‌توانید در یک حساب کاربری دیگر نقش متفاوتی داشته باشید.

آیا از ورود یک‌پارچه (SSO) برای دایرکتوری شرکت ما پشتیبانی می‌کنید؟

بله. هویت کاربران بر پایه Keycloak همراه با OIDC و SAML مدیریت می‌شود؛ بنابراین، ورود تک‌مرحله‌ای SAML برای مشتریان سازمانی و آژانس‌ها در دسترس است، در کنار ورود با لینک جادویی، ایمیل و رمز عبور، ارائه‌دهندگان اجتماعی، کلیدهای عبور (passkeys) و احراز هویت دومرحله‌ای TOTP که از طریق خط‌مشی اعمال می‌شود. یک نشست، داشبورد، سایت عمومی، پایگاه دانش و تیکت‌های پشتیبانی را پوشش می‌دهد.

از کجا بفهمم چه کسی تغییری ایجاد کرده است؟

هر اقدام سطح‌بالا در یک گزارش حسابرسی فقط‌افزودنی ثبت می‌شود که شامل عامل، اقدام، هدف، مستندات پشتیبان و نشانی IP است. خواندن آن یک مجوز مستقل است که هم به نقش مالک و هم به نقش فقط‌خواندنی اختصاص دارد، بنابراین مالک حساب و حسابرس می‌توانند تاریخچه یکسانی را بررسی کنند.

آیا افزودن اعضای تیم تغییری در مبلغ پرداختی من ایجاد می‌کند؟

طرح‌ها به‌جای تعداد افراد، بر اساس ظرفیت میزبانی قیمت‌گذاری می‌شوند. برای مثال، در خط تولید Footprint-Free، هر ۴۲ سطح دقیقا دارای مجموعه مزایای یکسانی هستند و تنها در تعداد سایت‌هایی که اجازه می‌دهند با یکدیگر تفاوت دارند. قیمت‌گذاری همواره از کاتالوگ زنده و با ارز شما محاسبه می‌شود، بنابراین آنچه در صفحه قیمت‌گذاری می‌بینید همان مبلغی است که در واقعیت دریافت می‌شود.

آیا می‌توانم پیش از خرید، آن را امتحان کنم؟

بله. دوره آزمایشی Footprint-Free چهارده روزه است، نیازی به اطلاعات کارت بانکی ندارد و تا ۵ سایت را پوشش می‌دهد؛ بنابراین می‌توانید پیش از پرداخت هرگونه هزینه‌ای، سازمان خود را راه‌اندازی کنید، تیم‌تان را دعوت کنید و نقش‌ها را روی کارهای واقعی بسنجید. طرح‌های پولی نیز دارای ضمانت بازگشت وجه ۳۰ روزه هستند.

تیم خود را در چند دقیقه راه‌اندازی کنید، نه با تیکت

یک دوره آزمایشی ۱۴ روزه بدون نیاز به کارت بانکی را در لاین Footprint-Free شروع کنید، تیم خود را دعوت کنید و قبل از پرداخت هرگونه هزینه، عملکرد نقش‌ها را روی سایت‌های واقعی ببینید.

شروع رایگان