راه‌اندازی جدول پایگاه داده توکن‌ها

بیایید با ایجاد یک جدول جدید tokens در پایگاه داده خود برای ذخیره توکن‌های فعال‌سازی کاربرانمان شروع کنیم. اگر می‌خواهید همراهی کنید، دستور زیر را برای ایجاد یک جفت فایل migration جدید اجرا کنید:

$ migrate create -seq -ext .sql -dir ./migrations create_tokens_table
/home/alex/Projects/greenlight/migrations/000005_create_tokens_table.up.sql
/home/alex/Projects/greenlight/migrations/000005_create_tokens_table.down.sql

سپس دستورات SQL زیر را به ترتیب به فایل‌های migration ‘up’ و ‘down’ اضافه کنید:

CREATE TABLE IF NOT EXISTS tokens (
    hash bytea PRIMARY KEY,
    user_id bigint NOT NULL REFERENCES users ON DELETE CASCADE,
    expiry timestamp(0) with time zone NOT NULL,
    scope text NOT NULL
);

DROP TABLE IF EXISTS tokens;

بیایید به سرعت ستون‌های این جدول جدید tokens را بررسی کرده و هدف هرکدام را توضیح دهیم.

• ستون hash شامل یک هش SHA-256 از توکن فعال‌سازی خواهد بود. مهم است تأکید کنیم که ما فقط هش توکن فعال‌سازی را در پایگاه داده ذخیره می‌کنیم — نه خود توکن فعال‌سازی را.

  دلیل اینکه می‌خواهیم توکن را قبل از ذخیره‌سازی هش کنیم، دقیقاً همان دلیلی است که رمز عبور کاربر را با bcrypt هش می‌کنیم — این کار لایه محافظتی اضافی در صورت نفوذ یا نشت پایگاه داده فراهم می‌کند. از آنجایی که توکن فعال‌سازی ما یک رشته تصادفی با آنتروپی بالا (۱۲۸ بیت) خواهد بود — برخلاف چیزی با آنتروپی پایین مانند رمز عبور معمولی کاربر — استفاده از الگوریتم سریعی مانند SHA-256 برای ایجاد هش کافی است، به جای الگوریتم کندی مانند bcrypt.

• ستون user_id شامل شناسه کاربر مرتبط با توکن خواهد بود. ما از سینتکس REFERENCES users برای ایجاد یک محدودیت foreign key روی کلید اصلی جدول users خود استفاده می‌کنیم، که تضمین می‌کند هر مقداری در ستون user_id دارای یک ورودی id متناظر در جدول users ما باشد.

  همچنین از سینتکس ON DELETE CASCADE استفاده می‌کنیم تا به PostgreSQL دستور دهیم به صورت خودکار تمام رکوردهای یک کاربر در جدول tokens ما را هنگام حذف رکورد والد در جدول users حذف کند.

• ستون expiry شامل زمانی خواهد بود که توکن ‘منقضی’ شده و دیگر معتبر نیست. تنظیم زمان انقضای کوتاه از نظر امنیتی خوب است زیرا به کاهش پنجره احتمال حمله brute-force موفق علیه توکن کمک می‌کند. همچنین در سناریویی که کاربر توکنی دریافت کرده اما از آن استفاده نکرده و حساب ایمیل آن‌ها در زمان بعدی به خطر بیفتد، مفید است. با تنظیم یک محدودیت زمانی کوتاه، پنجره زمانی که توکن به خطر افتاده می‌تواند مورد استفاده قرار گیرد، کاهش می‌یابد.

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

• ستون scope نشان می‌دهد توکن برای چه هدفی می‌تواند استفاده شود. بعداً در این کتاب همچنین نیاز داریم توکن‌های احراز هویت را ایجاد و ذخیره کنیم و بخش زیادی از کد و نیازهای ذخیره‌سازی برای آن‌ها دقیقاً مانند توکن‌های فعال‌سازی ما است. بنابراین به جای ایجاد جدول‌های جداگانه (و کد تعامل با آن‌ها)، آن‌ها را در یک جدول با مقداری در ستون scope برای محدود کردن هدف استفاده از توکن ذخیره می‌کنیم.

خب، با تمام این توضیحات، باید بتوانید مایگریشن ‘up’ را با دستور زیر اجرا کنید:

$ migrate -path=./migrations -database=$GREENLIGHT_DB_DSN up
5/u create_tokens_table (21.568194ms)