تبهای سفارشی اندروید، یک تجربه مرورگر کامل، امن و یکپارچه را مستقیماً در جریان ورود به شبکه برای پورتالهای تحت کنترل، مانند پورتالهای موجود در فرودگاهها، هتلها و هواپیماها، ارائه میدهند. تبهای سفارشی با ادغام مرورگر اصلی کاربر در فرآیند احراز هویت، قابلیتهای پیشرفتهای از جمله تکمیل خودکار فرمها با یک لمس برای اعتبارنامهها و پرداختها، پخش جریانی محافظتشده با DRM و اتصال پایدار برای کاربران با ویژگیهای امنیتی مانند VPN و DNS خصوصی را فراهم میکنند. برای اطلاعات بیشتر در مورد تبهای سفارشی، به نمای کلی تبهای سفارشی اندروید مراجعه کنید.
مزایای آن نسبت به WebView قدیمی
ادغام مرورگر اصلی کاربر با استفاده از تبهای سفارشی، چندین محدودیت عملکردی ذاتی در جریانهای احراز هویت مبتنی بر WebView قدیمی برای اپراتورهای شبکه را برطرف میکند:
- تراکنشهای ساده: رابط کاربری از تکمیل خودکار با یک لمس برای اعتبارنامهها و اطلاعات پرداخت ذخیرهشده پشتیبانی میکند و ورود دستی دادهها را در طول فرآیند ورود به سیستم کاهش میدهد. (شکل ۱ را ببینید.)
- سازگاری با رسانهها: این پلتفرم از محتوای محافظتشده توسط DRM (مانند Widevine) پشتیبانی میکند و امکان پخش جریانهای ویدیویی رمزگذاریشده را مستقیماً در داخل پورتال فراهم میکند. (شکل ۲ را ببینید.)
- پشتیبانی از پیکربندیهای امنیتی: تبهای سفارشی، عملکرد پورتال را برای دستگاههایی که از VPN یا DNS خصوصی استفاده میکنند، حفظ میکنند؛ ویژگیهای امنیتی که اغلب باعث میشوند ریدایرکتهای استاندارد مرورگر از کار بیفتند.
- سازگاری رابط کاربری: تبهای سفارشی مستقیماً با مرورگر سیستم ادغام میشوند و همان ابزارهای کاربردی و عناصر رابط کاربری موجود در یک جلسه کامل مرورگر را ارائه میدهند.
- پایداری در پسزمینه: پورتال در پسزمینه فعال میماند و در طول دوره اتصال به عنوان یک نقطه دسترسی پایدار عمل میکند.

شکل ۱. ورودی دستی (WebView) در مقابل تکمیل خودکار (Custom Tabs).

شکل ۲. عدم نمایش ویدیو (وب ویو) در مقابل پخش ویدیو (تبهای سفارشی).
کشف تبهای سفارشی و جریان اتصال
در حالی که تبهای سفارشی رابط کاربری را فراهم میکنند، رابط برنامهنویسی کاربردی پورتال کپتیو، جریان کشف تا اتصال هوشمند را مدیریت میکند:
- کشف: شبکه پشتیبانی API خود را با استفاده از گزینه DHCP 114 تبلیغ میکند.
- تعامل: دستگاه اندروید از نقطه پایانی API درخواست میکند تا یک فایل JSON حاوی وضعیت شبکه را دریافت کند.
- اتصال: اگر پاسخ JSON سیگنال استفاده از تبهای سفارشی را ارسال کند، سیستم به جای یک پنجره سیستمی ساده، پورتال را در یک محیط مرورگر با کارایی بالا باز میکند.
API پورتال تحت کنترل (Captive Portal API) به دستگاههای اندروید اجازه میدهد تا با استفاده از فیلد captive وجود یک پورتال تحت کنترل را تشخیص دهند. این API فیلدهای دیگری مانند venue-info-url و seconds-remaining را در رابط کاربری سیستم اندروید ادغام میکند.

شکل ۳. جریان کشف API پورتال تحت کنترل برای اتصال.
فعال کردن تبهای سفارشی اندروید
برای پشتیبانی از جریان تبهای سفارشی، اپراتورهای شبکه باید رابط برنامهنویسی کاربردی پورتال (Captive Portal API) را پیادهسازی کرده و از طریق پیکربندی JSON در آن مشارکت داشته باشند.
الزامات
فعال کردن تبهای سفارشی برای ورود به پورتال تحت کنترل، نیازمند موارد زیر است:
- دستگاهی که اندروید ۱۲ و بالاتر دارد و از بهروزرسانیهای سیستمی گوگل پلی (به Mainline مراجعه کنید) از طریق ماژول Mainline
CaptivePortalLoginپشتیبانی میکند. - پشتیبانی از رابط برنامهنویسی کاربردی پورتال ( RFC 8908 ). برای جزئیات بیشتر، به بخش «پشتیبانی از رابط برنامهنویسی کاربردی پورتال» مراجعه کنید.
به تبهای سفارشی اندروید بپیوندید
اگر شبکه شما از قبل از Captive Portal API (RFC 8908) پشتیبانی میکند، جفت کلید-مقدار زیر را به شیء پاسخ JSON موجود خود اضافه کنید تا جریان Custom Tabs فعال شود:
| کلید | ارزش | توضیحات |
|---|---|---|
x-android-use-custom-tabs | 361335020 | این مقدار نشان دهنده شماره نسخه ماژول Captive Portal Login Mainline است که در ژانویه 2026 منتشر شده است. دستگاههایی که بهروزرسانی ماژول آنها برابر یا جدیدتر از این نسخه است، از جریان ورود به سیستم Custom Tabs استفاده میکنند. |
این شیء JSON نمونه شامل تمام ویژگیهای پورتال تحت پشتیبانی اندروید است:
{
"captive": true,
"user-portal-url": "https://login.example.com",
"venue-info-url": "https://venue.example.com",
"seconds-remaining": 3600,
"x-android-use-custom-tabs": 361335020
}
ویژگیهای موجود برای پورتال تحت پوشش JSON به شرح زیر است:
-
captive: اگر احراز هویت لازم باشد، رویtrueتنظیم میشود؛ اگر کاربر از قبل آنلاین باشد، رویfalseتنظیم میشود. -
user-portal-url: آدرس صفحه ورود یا پرداخت. -
venue-info-url: لینکی به سایت شما برای اطلاعات (مثلاً جزئیات پرواز یا نقشه). -
seconds-remaining: مدت زمان باقیمانده (برحسب ثانیه) که انتظار میرود دستگاه اتصال اینترنت را حفظ کند را نشان میدهد. -
x-android-use-custom-tabs: کنترل میکند که آیا دستگاه در صورت وجود، از تب سفارشی استفاده کند یا خیر.
پشتیبانی از رابط برنامهنویسی کاربردی پورتال تحت مالکیت
اگر شبکه شما از Captive Portal API پشتیبانی نمیکند، این مراحل را برای فعال کردن Captive Portal API و جریان تبهای سفارشی دنبال کنید.
پیکربندی سرور DHCP خود را بهروزرسانی کنید تا گزینه DHCP 114 را نیز شامل شود.
مقدار: آدرس کامل HTTPS مربوط به فایل JSON تولید شده به صورت پویا که حاوی اطلاعات پورتال تحت کنترل است را ارائه دهید (برای مثال،
https://api.yourvenue.com/status).نتیجه: وقتی یک دستگاه اندروید به شبکه متصل میشود، به جای انتظار برای تغییر مسیر مرورگر، از API ارائه شده پرسوجو میکند.
سرور API خود را طوری پیکربندی کنید که به درخواست HTTP GET در URL ارائه شده با یک فایل JSON که دستگاه را از وضعیت فعلی پورتال مطلع میکند، پاسخ دهد.
الزام HTTPS: سرور API شما باید از یک گواهی HTTPS معتبر استفاده کند.
راهحل امنیتی جایگزین: اگر گواهی نامعتبر یا خودامضا باشد، دستگاه به رفتار پورتال تحت کنترل قدیمی برمیگردد.
رفتار تشخیص پورتال اسیر اندروید
رابط برنامهنویسی کاربردی پورتال تحت کنترل (Captive Portal API) جایگزین قابل اعتمادی برای کاوشگرهای شبکه استاندارد اندروید برای تشخیص وجود پورتال تحت کنترل ارائه میدهد و از ناسازگاریهای رایج جلوگیری میکند.
دستگاههای اندروید با ارسال همزمان کاوشگرهای HTTP و HTTPS به URLهای اعتبارسنجی خاص، دسترسی به شبکه را بررسی میکنند. موفقیت کاوشگر متناقض (برای مثال، HTTP موفق اما HTTPS ناموفق) منجر به وضعیت اتصال جزئی میشود که میتواند از نمایش خودکار برنامه ورود به سیستم جلوگیری کند.
رابط برنامهنویسی کاربردی پورتال تحت پوشش (Captive Portal API) با استفاده از رفتار تشخیص زیر، تشخیص را قابل اعتمادتر میکند:
- اگر API مقدار
"captive": trueگزارش کند، سیستم تشخیص میدهد که پشت یک پورتال قرار دارد و از بررسیهای استاندارد صرف نظر میکند تا بلافاصله رابط ورود به سیستم را نشان دهد. - اگر API مقدار
"captive": falseرا گزارش کند، سیستم با بررسیهای استاندارد پیش میرود و قبل از تأیید دسترسی کامل به اینترنت، نیاز به موفقیت هر دو بررسی HTTP و HTTPS دارد.