آموزش Credentials در n8n؛ مدیریت امن رمزها و توکن‌های API

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

بسیاری از این سرویس‌ها برای اجازه دسترسی، به اطلاعاتی مانند API Key، توکن دسترسی، نام کاربری و رمز عبور نیاز دارند. در n8n، این اطلاعات معمولاً از طریق قابلیتی به نام Credentials مدیریت می‌شوند.

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

Credentials در n8n چیست؟

Credentials در n8n محلی برای نگهداری و مدیریت اطلاعات احراز هویت سرویس‌هاست. به کمک این قابلیت می‌توانید اطلاعات لازم برای اتصال به یک سرویس را تعریف کنید و در Nodeهای مرتبط از آن استفاده کنید، بدون اینکه لازم باشد رمزها و توکن‌ها را به‌صورت دستی داخل هر درخواست قرار دهید.

برای مثال، فرض کنید یک Workflow دارید که باید هر روز اطلاعاتی را از یک API دریافت کند. این API برای دسترسی به داده‌ها به یک API Key نیاز دارد.

روش نامناسب این است که کلید را مستقیماً داخل URL، کد JavaScript یا متن Workflow بنویسید. روش بهتر این است که اعتبارنامه مناسب را ایجاد کنید و در Node مربوطه آن را انتخاب کنید.

Credentials به شما کمک می‌کند:

• اطلاعات احراز هویت را در یک محل مدیریت کنید.
• از اعتبارنامه در Nodeهای سازگار با آن استفاده مجدد کنید.
• نگهداری اطلاعات حساس را از منطق Workflow جدا کنید.
• مدیریت اتصال به سرویس‌های مختلف را ساده‌تر کنید.
• احتمال قرار گرفتن تصادفی رمزها و توکن‌ها در خروجی‌ها یا کدها را کاهش دهید.

البته استفاده از Credentials به‌تنهایی امنیت کامل ایجاد نمی‌کند؛ دسترسی کاربران، تنظیمات سرور، پشتیبان‌گیری و نحوه انتشار اطلاعات نیز اهمیت دارند.

تفاوت Credentials با Variables و Expressions چیست؟

این سه قابلیت ممکن است در ابتدا شبیه به هم به نظر برسند، اما کاربردهای متفاوتی دارند.

برای مثال، اگر می‌خواهید مقدار ایمیل دریافتی از یک Node قبلی را در درخواست بعدی استفاده کنید، معمولاً Expression انتخاب مناسبی است. اما اگر سرویس مقصد به یک توکن خصوصی نیاز دارد، باید از روش احراز هویت مناسب و در حالت معمول از Credentials استفاده کنید.

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

انواع روش‌های احراز هویت در n8n

نوع Credential موردنیاز به سرویسی بستگی دارد که می‌خواهید به آن متصل شوید. همه APIها از یک روش احراز هویت استفاده نمی‌کنند.

۱. API Key

در این روش، سرویس یک کلید اختصاصی در اختیار شما قرار می‌دهد. این کلید ممکن است در Header درخواست، پارامتر مشخصی از درخواست یا در موارد خاص در URL ارسال شود.

برای مثال، یک API ممکن است هدر زیر را انتظار داشته باشد:

X-API-Key: YOUR_API_KEY

در این مثال، YOUR_API_KEY یک مقدار فرضی است و باید با کلید واقعی خودتان جایگزین شود. بهتر است این مقدار از طریق سازوکار Credential مناسب مدیریت شود، نه اینکه مستقیماً در Workflow نوشته شود.

۲. Basic Authentication

در Basic Authentication، معمولاً نام کاربری و رمز عبور برای احراز هویت استفاده می‌شوند. اطلاعات این روش به شکل مشخصی در Header درخواست ارسال می‌شوند.

این روش را تنها زمانی انتخاب کنید که سرویس مقصد از آن پشتیبانی کند. همچنین از HTTPS استفاده کنید؛ Basic Authentication بدون یک ارتباط امن، برای محافظت از اطلاعات ورود کافی نیست.

۳. Bearer Token

بعضی سرویس‌ها برای دسترسی به API از توکن استفاده می‌کنند. در این حالت، درخواست معمولاً شامل هدر زیر است:

Authorization: Bearer YOUR_ACCESS_TOKEN

توکن واقعی باید محرمانه باقی بماند. اگر سرویس مقصد از Bearer Token استفاده می‌کند، نوع Credential و تنظیمات HTTP Request را مطابق مستندات همان سرویس انتخاب کنید.

۴. OAuth2

OAuth2 در بسیاری از سرویس‌ها برای اعطای دسترسی کنترل‌شده به API استفاده می‌شود. برای مثال، یک سرویس ممکن است به شما اجازه دهد حساب کاربری را متصل کنید و سپس n8n با استفاده از توکن‌های مدیریت‌شده درخواست‌ها را ارسال کند.

تنظیم OAuth2 معمولاً شامل مواردی مانند Client ID، Client Secret، آدرس‌های مجوزدهی و دریافت توکن و گاهی Scopeها است. مقادیر دقیق به سرویس موردنظر بستگی دارند.

در این روش، اگر سرویس و Node مربوطه پشتیبانی کنند، n8n می‌تواند فرایند مدیریت توکن را انجام دهد. برای سرویس‌هایی که تنظیمات OAuth2 اختصاصی دارند، مستندات رسمی آن سرویس و راهنمای همان Node را بررسی کنید.

چگونه در n8n یک Credential بسازیم؟

مراحل ایجاد اعتبارنامه با توجه به نسخه n8n و نوع Node ممکن است کمی تفاوت داشته باشد، اما روند کلی به این صورت است.

مرحله اول: Workflow جدید بسازید

وارد پنل n8n شوید و یک Workflow جدید ایجاد کنید یا Workflow موردنظر خود را باز کنید.

برای تمرین، می‌توانید از Node مربوط به HTTP Request استفاده کنید؛ این Node برای ارسال درخواست به APIها کاربرد دارد.

مرحله دوم: Node موردنظر را اضافه کنید

یک Node از نوع HTTP Request به Workflow اضافه کنید.

در این Node می‌توانید آدرس API، روش درخواست مانند GET یا POST، پارامترها، Headerها و تنظیمات احراز هویت را مشخص کنید.

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

مرحله سوم: بخش Authentication را بررسی کنید

در تنظیمات HTTP Request، بخش Authentication را پیدا کنید.

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

اگر نوع احراز هویت API شما در فهرست موجود است، همان گزینه را انتخاب کنید. برای مثال، ممکن است از API Key، Basic Auth یا Generic Credential استفاده کنید.

مرحله چهارم: Credential مناسب را ایجاد کنید

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

نوع اعتبارنامه را متناسب با سرویس انتخاب کنید و اطلاعات موردنیاز را وارد کنید.

برای نمونه، یک API Key ممکن است به اطلاعاتی مانند موارد زیر نیاز داشته باشد:

• محل ارسال کلید، مانند Header یا Query Parameter
• نام Header یا پارامتر مورد انتظار API
• مقدار کلید API

این فیلدها در همه Credentialها یکسان نیستند. نام و محل دقیق مقدار را از مستندات API مقصد بردارید.

مرحله پنجم: اعتبارنامه را ذخیره کنید

پس از وارد کردن اطلاعات، Credential را ذخیره کنید. اگر n8n امکان انتخاب اعتبارنامه ذخیره‌شده را در Node موردنظر فراهم می‌کند، همان Credential را انتخاب کنید.

در این مرحله، از قرار دادن دوباره کلید واقعی در فیلدهای دیگر خودداری کنید؛ مگر اینکه مستندات سرویس و تنظیمات احراز هویت واقعاً چنین کاری را لازم بدانند.

مرحله ششم: اتصال را آزمایش کنید

Node را اجرا کنید و نتیجه درخواست را بررسی کنید.

اگر درخواست موفق باشد، معمولاً API پاسخی متناسب با مستندات خود برمی‌گرداند. با این حال، موفقیت درخواست به معنی صحیح بودن تمام تنظیمات Workflow نیست؛ لازم است ساختار داده و وضعیت پاسخ را نیز بررسی کنید.

اگر خطا دریافت کردید، بخش عیب‌یابی انتهای مقاله را بخوانید.

مثال عملی: اتصال HTTP Request به یک API

فرض کنید یک سرویس آزمایشی دارید که برای دریافت اطلاعات به API Key نیاز دارد.

در این مثال، آدرس زیر صرفاً نمونه است:

https://api.example.com/v1/products

این آدرس واقعی یک سرویس مشخص نیست؛ بنابراین قبل از اجرای نمونه در پروژه واقعی، باید آن را با آدرس API موردنظر خود جایگزین کنید.

تنظیم Node

در HTTP Request تنظیمات کلی زیر را انجام دهید:

1. Method: مقدار GET را انتخاب کنید.
2. URL: آدرس API واقعی را وارد کنید.
3. Authentication: روش پشتیبانی‌شده توسط API را انتخاب کنید.
4. Credential: اعتبارنامه‌ای را که ساخته‌اید انتخاب کنید.
5. Execute Step: درخواست را اجرا کنید.

اگر API به API Key در Header نیاز دارد، باید نام Header و مقدار کلید مطابق مستندات سرویس تنظیم شده باشند. اگر Credential آماده و اختصاصی برای آن سرویس وجود دارد، بهتر است ابتدا از همان استفاده کنید.

نمونه پاسخ موفق

فرض کنید سرویس نمونه، پاسخ JSON زیر را برمی‌گرداند:

{

  "success": true,

  "products": [

    {

      "id": 101,

      "name": "Keyboard"

    },

    {

      "id": 102,

      "name": "Mouse"

    }

  ]

}

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

پس از دریافت پاسخ، می‌توانید داده‌ها را در Nodeهای بعدی مانند Edit Fields، IF یا Code پردازش کنید. در این مرحله، اطلاعات محصولات بخشی از داده‌های Workflow هستند؛ اما API Key همچنان باید در بخش احراز هویت مدیریت شود، نه اینکه به‌عنوان یک فیلد معمولی وارد داده‌های کسب‌وکار شود.

آیا می‌توان یک Credential را در چند Node استفاده کرد؟

بله، در بسیاری از موارد می‌توانید یک Credential ذخیره‌شده را در چند Node سازگار با همان نوع اعتبارنامه انتخاب کنید.

برای مثال، اگر دو HTTP Request به یک سرویس و با یک روش احراز هویت متصل می‌شوند، ممکن است بتوانید در هر دو Node همان Credential را انتخاب کنید.

این کار چند مزیت دارد:

• از وارد کردن مکرر اطلاعات جلوگیری می‌کند.
• به‌روزرسانی اعتبارنامه را ساده‌تر می‌کند.
• احتمال تفاوت تصادفی در تنظیمات احراز هویت را کاهش می‌دهد.

البته یک Credential لزوماً با همه Nodeها سازگار نیست. سازگاری به نوع Credential، نوع Node و روش احراز هویت مورد پشتیبانی بستگی دارد.

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

چگونه Credential را ویرایش یا حذف کنیم؟

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

ویرایش Credential

اگر API Key تغییر کرده یا رمز عبور سرویس عوض شده است، اعتبارنامه مربوطه را باز کنید و در صورت پشتیبانی، مقدار جدید را ذخیره کنید.

پس از تغییر، Workflowهای وابسته را آزمایش کنید تا مطمئن شوید اتصال همچنان کار می‌کند.

حذف Credential

اگر دیگر به یک Credential نیاز ندارید، قبل از حذف آن بررسی کنید کدام Workflowها از آن استفاده می‌کنند.

حذف اعتبارنامه ممکن است باعث شود Nodeهای وابسته دیگر نتوانند درخواست موفق ارسال کنند. بنابراین، ابتدا وابستگی‌ها را بررسی و در صورت نیاز Credential جایگزین را تنظیم کنید.

چرخش کلیدها و توکن‌ها

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

نکات امنیتی مهم هنگام استفاده از Credentials

مدیریت صحیح Credentials فقط به ایجاد یک اعتبارنامه محدود نمی‌شود. اگر Workflow شما به سرویس‌های مهم یا داده‌های کاربران دسترسی دارد، رعایت نکات زیر ضروری است.

۱. کلیدها را مستقیماً داخل Code Node ننویسید

فرض کنید می‌خواهید با JavaScript یک درخواست به API ارسال کنید. قرار دادن کلید واقعی در کد، راهکار مناسبی برای مدیریت اطلاعات محرمانه نیست.

نمونه نامناسب:

const apiKey = "REAL_SECRET_API_KEY";

این مثال عمداً از یک مقدار ساختگی استفاده می‌کند. در پروژه واقعی، کلید را داخل کد قرار ندهید؛ از روش احراز هویت و امکاناتی استفاده کنید که n8n و سرویس مقصد پشتیبانی می‌کنند.

Code Node برای پردازش داده‌ها و اجرای منطق برنامه مناسب است، اما نباید آن را راهی برای دور زدن مدیریت اعتبارنامه‌ها در نظر گرفت.

۲. از انتشار توکن در خروجی Workflow جلوگیری کنید

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

بنابراین:

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

پنهان بودن یک فیلد در رابط کاربری را معادل محرمانه ماندن آن در تمام مراحل پردازش فرض نکنید.

۳. از حداقل سطح دسترسی استفاده کنید

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

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

این اصل با عنوان Least Privilege یا «حداقل سطح دسترسی» شناخته می‌شود.

۴. از HTTPS استفاده کنید

هنگام اتصال به APIهای خارجی، از HTTPS استفاده کنید؛ مگر در شرایط داخلی و کنترل‌شده‌ای که معماری سرویس نیاز دیگری داشته باشد.

HTTPS از ارتباط در مسیر شبکه محافظت می‌کند، اما جایگزین مدیریت امن Credential یا کنترل دسترسی نیست.

۵. کلید رمزنگاری n8n را حفظ کنید

n8n برای محافظت از داده‌های Credential ذخیره‌شده از سازوکار رمزنگاری استفاده می‌کند. در استقرارهای معمول، کلید رمزنگاری با تنظیمات محیطی n8n و به‌ویژه N8N_ENCRYPTION_KEY مرتبط است؛ اگر این مقدار را مشخص نکرده باشید، رفتار آن به شیوه نصب و نسخه n8n بستگی دارد.

اگر n8n را با Docker یا Coolify اجرا می‌کنید، تنظیمات و متغیرهای محیطی سرویس را بررسی کنید.

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

برای انتقال n8n به سرور دیگر، تنها کپی کردن Workflowها و پایگاه داده ممکن است کافی نباشد؛ باید روش صحیح انتقال تنظیمات و کلید رمزنگاری را نیز مطابق مستندات نسخه خود بررسی کنید.

۶. دسترسی به Credentials را محدود کنید

اگر چند کاربر یا تیم در یک محیط n8n کار می‌کنند، بررسی کنید چه کسانی اجازه مشاهده یا استفاده از Workflowها و Credentialها را دارند.

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

خطاهای رایج Credentials در n8n و روش رفع آن‌ها

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

خطای 401 Unauthorized

این خطا معمولاً به مشکل احراز هویت اشاره می‌کند.

موارد زیر را بررسی کنید:

• آیا API Key یا توکن معتبر است؟
• آیا کلید لغو یا منقضی شده است؟
• آیا روش احراز هویت با مستندات API مطابقت دارد؟
• آیا توکن در Header یا محل صحیح ارسال می‌شود؟
• آیا Credential انتخاب‌شده همان اعتبارنامه موردنظر است؟

در برخی سرویس‌ها، خطای 401 می‌تواند دلایل دیگری هم داشته باشد؛ بنابراین فقط با دیدن این خطا نتیجه قطعی نگیرید.

خطای 403 Forbidden

این خطا اغلب به محدودیت دسترسی مربوط می‌شود.

ممکن است اعتبارنامه معتبر باشد، اما اجازه انجام عملیات موردنظر را نداشته باشد. سطح دسترسی کلید، مجوز حساب، Scopeهای OAuth2 و محدودیت‌های API را بررسی کنید.

خطای 404 Not Found

در این حالت، ممکن است آدرس API اشتباه باشد یا منبع درخواستی وجود نداشته باشد.

آدرس، مسیر Endpoint، شناسه منبع و نسخه API را با مستندات سرویس مقایسه کنید.

خطای اتصال یا Timeout

اگر درخواست به سرویس مقصد نمی‌رسد، موارد زیر را بررسی کنید:

• آدرس و پورت سرویس مقصد
• دسترسی شبکه از سرور n8n
• تنظیمات DNS و فایروال
• در دسترس بودن سرویس مقصد
• محدودیت‌های زمانی درخواست

این خطاها لزوماً به Credential مربوط نیستند؛ ممکن است اطلاعات احراز هویت صحیح باشند، اما ارتباط شبکه برقرار نشود.

Credential ذخیره شده، اما درخواست همچنان ناموفق است

ذخیره شدن اعتبارنامه به معنی موفق بودن اتصال نیست. ممکن است نوع Credential انتخاب‌شده با API سازگار نباشد یا Node از آن نوع احراز هویت پشتیبانی نکند.

تنظیمات Node و مستندات سرویس را بررسی کنید و در صورت تغییر کلید یا رمز، اعتبارنامه را به‌روزرسانی و دوباره آزمایش کنید.

بهترین روش مدیریت Credentials در پروژه‌های واقعی

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

1. نام‌گذاری واضح: نام Credential را بر اساس سرویس و کاربرد آن انتخاب کنید؛ برای مثال، نامی که مشخص کند اعتبارنامه مربوط به API محصولات محیط آزمایشی است.
2. تفکیک محیط‌ها: تا جای ممکن اعتبارنامه‌های محیط توسعه، آزمایش و تولید را از یکدیگر جدا کنید.
3. محدود کردن دسترسی: هر Credential را با کمترین مجوز لازم بسازید.
4. مستندسازی وابستگی‌ها: مشخص کنید هر اعتبارنامه توسط کدام Workflowها استفاده می‌شود.
5. تعویض منظم و کنترل‌شده: کلیدهای منقضی یا افشاشده را مدیریت کنید و پس از تغییر، اتصال‌ها را آزمایش کنید.
6. پشتیبان‌گیری امن: علاوه بر داده‌های n8n، تنظیمات ضروری برای بازیابی امن Credentialها را نیز در برنامه پشتیبان‌گیری در نظر بگیرید.
7. عدم انتشار اسرار: کلیدها و رمزها را در کد، مستندات عمومی، لاگ‌ها و تصاویر قابل انتشار قرار ندهید.

جمع‌بندی

Credentials در n8n یکی از قابلیت‌های اصلی برای اتصال امن Workflowها به APIها و سرویس‌های خارجی است. به کمک آن می‌توانید اطلاعات احراز هویت را از منطق پردازش داده‌ها جدا کنید، از اعتبارنامه‌های ذخیره‌شده استفاده مجدد کنید و مدیریت اتصال‌ها را ساده‌تر انجام دهید.

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

اگر n8n را روی سرور شخصی یا از طریق Docker و Coolify اجرا می‌کنید، حفاظت از کلید رمزنگاری و داشتن برنامه پشتیبان‌گیری امن نیز بخشی از مدیریت صحیح اعتبارنامه‌هاست.

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

Credentials در n8n چه کاربردی دارد؟

Credentials برای نگهداری و مدیریت اطلاعات احراز هویت سرویس‌ها استفاده می‌شود؛ مانند API Key، نام کاربری و رمز عبور یا تنظیمات OAuth2. Nodeهای سازگار می‌توانند از این اعتبارنامه‌ها برای برقراری اتصال استفاده کنند.

آیا می‌توان API Key را مستقیماً در HTTP Request وارد کرد؟

برخی تنظیمات HTTP Request امکان تعریف دستی Header یا پارامتر را فراهم می‌کنند، اما برای اطلاعات محرمانه بهتر است از روش Credential پشتیبانی‌شده استفاده کنید تا احتمال افشای کلید کاهش پیدا کند.

تفاوت Credentials با Variables در n8n چیست؟

Credentials برای اطلاعات احراز هویت و اتصال امن به سرویس‌ها طراحی شده است؛ Variables برای نگهداری برخی مقادیر قابل استفاده مجدد کاربرد دارد و امکانات آن به نسخه و تنظیمات n8n وابسته است. این دو را جایگزین یکدیگر در نظر نگیرید.

آیا Credentials در n8n رمزگذاری می‌شود؟

n8n از سازوکار رمزنگاری برای داده‌های Credential ذخیره‌شده استفاده می‌کند. با این حال، امنیت نهایی به حفاظت از کلید رمزنگاری، دسترسی کاربران، تنظیمات سرور و نحوه نگهداری خروجی‌ها و نسخه‌های پشتیبان نیز وابسته است.

اگر کلید رمزنگاری n8n را تغییر دهم چه می‌شود؟

اگر کلید جدید با کلیدی که داده‌های موجود با آن رمزگذاری شده‌اند هماهنگ نباشد، ممکن است n8n نتواند Credentialهای قبلی را رمزگشایی کند. پیش از تغییر یا مهاجرت، مستندات رسمی نسخه خود را بررسی کنید و از داده‌ها و تنظیمات ضروری نسخه پشتیبان امن تهیه کنید.

آیا Credentials برای همه Nodeهای n8n قابل استفاده است؟

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

برای امنیت بیشتر در n8n چه کاری انجام دهم؟

از Credential مناسب استفاده کنید، دسترسی‌ها را محدود کنید، کلیدها را در کد یا لاگ‌ها منتشر نکنید، از HTTPS استفاده کنید و کلید رمزنگاری و پشتیبان‌های خود را به‌صورت امن نگهداری کنید.