کلید و رمز

یک API key رشته‌ی بلندی از حرف و عدد است که به یک سرویس می‌گوید «این درخواست از طرف من است، به حساب من». همین.

و مهم‌ترین جمله‌ی این فصل همین اول گفته می‌شود:

به‌خاطر بسپار کلید = رمز + کارت بانکی، در یک رشته. هر کسی که آن را داشته باشد می‌تواند به حساب تو از سرویس استفاده کند — و صورت‌حسابش را تو می‌پردازی. با رمز ایمیلت یکی رفتار کن، نه با یک تنظیم.

سه ویژگی که رفتارِ درست با کلید را روشن می‌کنند:

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

به ترتیب از بهترین به بدترین:

• ۱ — مدیر رمز سیستم‌عامل. روی مک Keychain، روی ویندوز Credential Manager. رمزنگاری‌شده، و در هیچ فایلی که ممکن است اشتباهی کپی شود نیست. بهترین گزینه، و کم‌تر از همه استفاده می‌شود.
• ۲ — فایل env در پوشه‌ی پروژه. رایج‌ترین راه و برای کارِ ما قابل قبول است، به شرط رعایتِ بخش بعد.
• ۳ — متغیر محیطی موقت در ترمینال. برای یک بار امتحان‌کردن خوب است؛ با بستن پنجره می‌رود.
• ۴ — مدیر رمزِ خودت (همان‌جایی که رمزهای دیگرت هستند) به عنوان نسخه‌ی پشتیبان، تا اگر گمش کردی لازم نباشد از نو بسازی.

و هیچ‌وقت: داخل خودِ کد، در یک فایل متنیِ روی دسکتاپ، در یادداشتی که با کسی همگام می‌شود، یا در پیامی که به خودت فرستادی.

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

یک فایل متنی ساده به نام .env که سطرهایش این شکل‌اند:

SERVICE_API_KEY=sk-xxxxxxxxxxxx

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

ولی این مزیت فقط با یک قاعده برقرار می‌ماند:

به‌خاطر بسپار نام .env باید در فایل .gitignore باشد، وگرنه git آن را هم ثبت می‌کند — و آن‌وقت کلیدت وارد تاریخچه‌ای می‌شود که فصل ۵.۲.۲ گفت نقطه‌هایش پاک نمی‌شوند. یعنی حتی اگر بعداً فایل را حذف کنی، کلید در نسخه‌های قبلی هست.

سه عادتِ همراهش که کار را تمیز می‌کنند:

• یک فایل نمونه بساز — .env.example با همان نام‌ها ولی بدون مقادیر. این هم به خودت یادآوری می‌کند چه کلیدهایی لازم است، و هم مشکلِ شماره‌ی ۲ فصل ۷.۴.۳ را حل می‌کند.
• یک بار چک کن. از ایجنت بخواه بگردد ببیند کلیدی جایی در پروژه‌ات به‌صورت مستقیم نوشته شده یا نه. این کارِ دو دقیقه‌ای است و ارزشش را دارد.
• و در فایل قانونت بنویس که کلیدها کجا هستند و هیچ‌وقت جای دیگری نمی‌روند (فصل ۶.۴) — تا فرضِ خودت هم نوشته باشد، نه فقط در سرت.

چهار کار، و برای هر کدام چرا:

1. کلید را در کد نگذار. چون کد کپی می‌شود، به اشتراک گذاشته می‌شود، و در تاریخچه می‌ماند. کلید در کد یعنی کلیدی که دیگر کنترلش دستت نیست.
2. کلید را در تصویر یا اسکرین‌شات نشان نده. این شایع‌ترین لو رفتنِ ناخواسته است — کسی موقع پرسیدن سؤال، عکسِ ترمینالش را می‌فرستد.
3. کلید را در مخزن عمومی نگذار. و بدان که ربات‌هایی مخصوصاً مخزن‌های عمومی را برای کلید می‌گردند. فاصله‌ی بین «اشتباهی فرستادم» و «استفاده شد» می‌تواند دقیقه باشد، نه روز.
4. و کلیدت را به کسی نده — حتی برای «یک بار امتحان». اگر واقعاً لازم است، برایش کلید جدا بساز که بتوانی بعداً فقط همان را باطل کنی.

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

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