آدرس canonical جدید ICP یک مرز هویتی و امنیتی است

نشانی canonical مربوط به frontend در اینترنت کامپیوتر به سمت icp.net در حال حرکت است، اما توسعه‌دهندگان باید آن را به‌عنوان تغییری در مرز برنامه در نظر بگیرند، نه صرفاً جایگزینی یک URL.

اولین نشانه روشن این تغییر در نسخه 1.0.0 ابزار icp-cli دیده شد؛ یادداشت انتشار این نسخه، دامنه پیش‌فرض gateway را از icp0.io به icp.net تغییر داد. مستندات فعلی ICP نیز اکنون https://<canister-id>.icp.net را به‌عنوان نشانی استاندارد mainnet برای asset canisterها معرفی می‌کند و همین hostname را در نمونه‌های اعتبارسنجی دامنه سفارشی به کار می‌برد.

اهمیت این تغییر از آن‌جاست که origin برنامه در احراز هویت نقش دارد. Internet Identity، principal کاربر را از origin مربوط به frontend استخراج می‌کند. راهنمای فعلی احراز هویت می‌گوید ارائه یک برنامه از چند دامنه می‌تواند principalهای متفاوتی ایجاد کند؛ بنابراین اگر برنامه از URL مربوط به canister به یک دامنه سفارشی منتقل شود، برای حفظ همان هویت کاربران باید alternative origin پیکربندی شود. این راهنما یک قاعده سازگاری ویژه برای icp0.io و ic0.app نیز مستند کرده است، اما این قاعده را نباید به دامنه‌های دلخواه تعمیم داد.

برای سازندگان، چک‌لیست مهاجرت کوتاه اما مهم است:

1. URL canonical تولید را در یادداشت‌های deployment، تنظیمات محیطی و تست‌های یکپارچه‌سازی صریح کنید.
2. تداوم ورود را هنگام جابه‌جایی میان URL قدیمی gateway، icp.net و دامنه سفارشی آزمایش کنید.
3. اگر قرار است دو origin سفارشی واقعی کاربران مشترکی داشته باشند، فایل /.well-known/ii-alternative-origins را از origin اصلی منتشر کنید و originهای دقیق، بدون مسیر یا slash پایانی، در آن قرار دهید.
4. تا حد امکان JavaScript، CSS و سایر دارایی‌های حساس را روی origin دارای گواهی canister نگه دارید.

نکته امنیتی در همین بخش است. راهنمای کنترل canister در ICP هشدار می‌دهد که بارگذاری JavaScript از یک دامنه غیرقابل‌اعتماد، کنترل context مرورگر برنامه را به آن دامنه می‌دهد؛ این موضوع می‌تواند شامل به خطر انداختن اعتبارنامه‌هایی باشد که agent جاوااسکریپت مدیریت می‌کند. همان راهنما <canister-id>.icp.net را origin دارای اعتماد و گواهی معرفی می‌کند و هشدار می‌دهد که دامنه‌های raw gateway همان تضمین گواهی دارایی را ارائه نمی‌کنند.

درس عملی این است که icp.net به یک نقطه اتکای canonical برای routing و بازبینی امنیتی تبدیل می‌شود. مهاجرت URL همچنان می‌تواند sessionها را بشکند، اگر origin تغییر کند؛ و یک frontend ظاهراً یکسان نیز ممکن است ناامن باشد، اگر اسکریپت‌های آن از host دیگری بارگذاری شوند.

ملاحظه: منابع، پیش‌فرض فعلی icp.net و پیامدهای هویتی آن را تأیید می‌کنند، اما برای حذف URLهای قدیمی gateway یک مهلت عمومی و قطعی اعلام نمی‌کنند. زمان‌بندی مهاجرت ممکن است بسته به ابزار و برنامه متفاوت باشد.