Chrome 124 شامل مجوز دسترسی به شبکه خصوصی برای آرام کردن ویژگی محتوای ترکیبی است. برای سایت‌هایی که به زمان بیشتری برای آماده شدن برای این تغییر نیاز دارند، یک دوره آزمایشی منسوخ در حال انجام است، اما این آزمایشی با Chrome 132 به پایان می‌رسد، که انتظار می‌رود در 4 فوریه 2025 ارسال شود. این پست تغییرات را توضیح می‌دهد، بیشتر در مورد طراحی ویژگی، نحوه ارائه آن برای مهاجرت وب سایت های فعلی خود و نحوه آزمایش پیاده سازی خود.
چه چیزی در حال تغییر است؟
برای برقراری اتصال به دستگاه‌هایی در یک شبکه خصوصی که نام‌های منحصربه‌فرد جهانی ندارند و بنابراین نمی‌توانند گواهی‌های TLS را دریافت کنند، این ویژگی گزینه جدیدی را برای fetch() معرفی می‌کند تا قصد توسعه‌دهندگان را برای صحبت با چنین دستگاهی اعلام کند. این شامل یک ویژگی جدید کنترل شده توسط سیاست برای دریچه دسترسی هر سایت به این قابلیت و سرصفحه های جدید برای پاسخ پیش از پرواز سرور برای ارائه ابرداده های اضافی است.
دسترسی به شبکه خصوصی چیست؟
دسترسی به شبکه خصوصی (PNA، که قبلا با نام CORS-RFC1918 و به طور خلاصه به عنوان دسترسی به شبکه محلی شناخته می شد) یک ویژگی امنیتی است که توانایی وب سایت ها را برای ارسال درخواست به سرورها در شبکه های خصوصی محدود می کند. این به محافظت از کاربران و شبکه‌های داخلی در برابر حملات احتمالی مانند جعل درخواست بین سایتی (CSRF) کمک می‌کند. کروم به تدریج PNA را پیاده سازی کرده است و حفاظت در نسخه های آینده گسترش خواهد یافت.
چرا درخواست مجوز لازم است؟
کروم 94 یک بلوک برای دسترسی به شبکه خصوصی از وب‌سایت‌های عمومی غیر ایمن معرفی کرد. دسترسی مداوم به شبکه خصوصی از طریق آزمایش منسوخ شدن زمینه‌های غیرایمن، چالش‌هایی را در انتقال وب‌سایت‌های آسیب‌دیده به HTTPS نشان داده است. یکی از نگرانی‌های رایج دشواری انتقال دستگاه‌های خصوصی به HTTPS است که منجر به نقض مختلط بررسی محتوا می‌شود.
برای مقابله با این چالش، یک درخواست مجوز جدید تحت یک آزمایش اولیه از Chrome 120، و در پایدار از Chrome 124 اضافه شد.
چه زمانی به درخواست مجوز نیاز است؟
ما قصد داشتیم چند مرحله پس از در دسترس شدن ویژگی درخواست مجوز، به آزمایش منسوخ شدن زمینه‌های غیرایمن پایان دهیم. برای اطمینان از سازگاری، باید وب سایت های عمومی خود را به HTTPS منتقل کنید. اگر نمی‌توانید سرور خصوصی خود را به HTTPS منتقل کنید، ویژگی جدید درخواست مجوز به شما امکان می‌دهد بررسی محتوای مختلط را کاهش دهید.
یک گردش کار معمولی برای درخواست دسترسی به شبکه خصوصی با درخواست مجوز به شرح زیر است.
درخواست مجوز را راه اندازی کنید
ویژگی جدید targetAddressSpace را به عنوان گزینه واکشی اضافه کنید، سپس درخواست می تواند بررسی محتوای ترکیبی را رد کند.
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
مطابق با دسترسی به شبکه خصوصی: معرفی پروازهای پیش از پرواز ، قبل از هر درخواست شبکه خصوصی یک درخواست قبل از پرواز ارائه می شود. این درخواست پیش از پرواز شامل یک هدر جدید است، Access-Control-Request-Private-Network: true ، و پاسخ مربوطه باید شامل سرصفحه Access-Control-Allow-Private-Network: true باشد.
برای انطباق با درخواست مجوز جدید، دستگاه‌ها باید دو سرصفحه پاسخ جدید را وارد کنند: Private-Network-Access-Name و Private-Network-Access-ID .
-
Private-Network-Access-ID: یک مقدار 48 بیتی ارائه شده به صورت 6 بایت هگزادسیمال که با دو نقطه از هم جدا شده اند. -
Private-Network-Access-Name: نام معتبری به عنوان رشته ای که با عبارت منظم ECMAScript مطابقت دارد/^[a-z0-9_-.]+$/.حداکثر طول نام 248 واحد کد UTF-8 است.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
نسخه ی نمایشی
می توانید نسخه ی نمایشی را در: https://private-network-access-permission-test.glitch.me/ بررسی کنید.
برای استفاده از وب سایت دمو باید سرور خصوصی شخصی خود را راه اندازی کنید. سرور خصوصی باید با هدر HTTP Access-Control-Allow-Private-Network: true ، همراه با سرصفحه های مشخص شده توسط سرور Private-Network-Access-ID و Private-Network-Access-Name پاسخ دهد. اگر همه چیز به درستی تنظیم شده باشد، دستور مجوز زیر باید نشان داده شود:
از دوره آزمایشی منسوخ شدن زمینه غیرایمن خارج شوید
برای وب‌سایت‌هایی که دسترسی به شبکه خصوصی را برای آزمایش منسوخ شدن زمینه‌های غیرایمن ثبت کرده‌اند، اکنون زمان آن است که وب‌سایت خود را با درخواست مجوز جدید ما انتقال دهید و اکنون از دوره آزمایشی خارج شوید.
پس از به‌روزرسانی کد، توکن آزمایشی را در هدرهای HTML، جاوا اسکریپت یا HTTP خود حذف کنید. اگر به خاطر نمی آورید که رمز آزمایشی را کجا قرار داده اید، به بخش ثبت نام آزمایشی منسوخ در پست قبلی وبلاگ مراجعه کنید.
همچنین ممکن است بخواهید رمز موجود در صفحه آزمایشی را حذف کنید.
بعدش چی؟
راه حل برای درخواست های غیر API fetch() هنوز در دست کاوش است.
چندین راه حل آزمایش شده است، به عنوان مثال، استفاده از کارکنان خدمات یا ایجاد فضای آدرس هدف به عنوان یک Content-Security-Policy جدید. با این حال شکل نهایی برای درخواست‌های غیر API fetch() هنوز در دست بررسی است.
درخواست‌های فریم‌های فرعی ممکن است در آینده با خط‌مشی مجوز پشتیبانی شوند.
در آینده، ممکن است بخواهیم از سیاست‌های مجوز برای کاهش توانایی فریم‌های فرعی پشتیبانی کنیم.
بازخورد برای موارد استفاده از شبکه خصوصی
اگر وب‌سایتی را در یک شبکه خصوصی میزبانی می‌کنید که به درخواست‌های شبکه‌های عمومی نیاز دارد، تیم Chrome بازخورد شما را می‌خواهد! مشکل را در ردیاب مشکلات Chromium (جزء: Blink>SecurityFeature>CORS>PrivateNetworkAccess) یا در مخزن GitHub ثبت کنید.