In the area of WiFi certification, equipment compatibility is a seemingly unseemly but actually very influential problem. If only tested on several of your own test devices, there are strange end-point problems that come up online: one national cell phone can't get Portal pages, one version of iOS on HTTPS Portal white screens, and an old notebook browser does not support authentication buttons on the web page.……These problems are fragmented, difficult to repeat, inefficient to check, but each one of them affects the experience of a group of users. Considering compatibility as an independent dimension of system design reduces the amount of fire-fighting work that goes on line.
The compatibility of Portal's ejection is the first level.
The detection mechanisms for Captive Portal vary from operating system to system. iOS uses captivive.apple.com as a detection address, Android uses contractivitycheck.gstatic.com, Windows uses msftncsi.com.——iOS requests to return HTTP 200 and the page is"Success", some Android versions require return of HTTP 204. IfWiFi certification systemThe user's device doesn't pop the Portal window, nor does it show on the WiFi icon."Login required"The hint.
The correct approach is: NATSHEL_AUTH_GATEWAY needs to identify these known detection addresses when intercepting HTTP requests, responding to expectations for the return of the detection address (iOS returns 200 and content Suaccess, Android returns 204), and directing 302 re-directions to Portal pages only to other normal requests. This logic seems simple, but often in actual deployments inconsistently due to differences in the configuration of different brands of network equipment. The best way to achieve this is at the NATSHEL_AUTH_GATEWAY software level, which does not rely on network equipment ACL configurations for differentiation, so that consistency of behaviour can be ensured under different network equipment models.
There are also special cases: some versions of Android automatically switch to mobile data networks for loading the current page when WiFi is detected without network access, resulting in Portal not showing at all. This requires equipment manufacturer-level adaptations, and what can be done on the side of the certification system by adding a clear hint to Portal:"Please close the moving data in WiFi settings and try again". Although this reminder does not solve all problems, it gives at least some user guidance.
Certificate compatibility for HTTPS Portal pages.
For security and user experience, most Portal authentication pages now use the HTTPS protocol. But HTTS relies on TLS certificates, unlike the version of the root certificate that was pre-fabricated on different devices. An Android phone bought three years ago may not be updated because the system has never been updated, and a new CA certificate is missing from the root certificate library, which will be reported when accessing Portal page."Connections are not safe."The warning.
The normal approach to this problem is that certificates used by Portal servers are from mainstream CA agencies (e.g. DigiCert, GlobalSign, Let)'S Entert) issues, and these CA root certificates have the widest reach. At the same time, the server-end configuration of TLS should not only support the latest TLS 1.3 protocol——Many old devices support TLS 1.2 or even TLS 1.1, and if the server accepts only TLS 1.3 connections, these older devices are completely unable to open Portal pages. The correct configuration is both TLS 1.2 and TLS 1.3, while TLS 1.1 depends on whether equipment distribution data will continue to support them.
In practice, we also keep a HTTP version of Portal as a downgrade. When User-Agent is detected to be a known HTTPS-compatible device, it automatically descends to the HTTP page. This is not the safest approach, but an acceptable engineering compromise in the reality that all equipment cannot be perfectly supported by HTTPS.
The kernel fragmentation of the browser.
Portal authenticates pages on browsers, and the browser environment on mobile devices is extremely fragmented. Micro-trust in-house browsers, cell phone vendor-banded browsers, Chrome, Safari, UC browsers——Their support for HTML5/CSScript varies. A perfect display of the authentication page on Chrome may cause a disruption of layouts on micro-letter internal browsers because some CSS properties are not supported, and on UC browsers may cause logical anomalies in form submission due to differences in JavaScript engines.
The response is to keep the technology warehouse on Portal as simple as possible. Without a complex CSS layout, not relying on the frontline JavaScript API, not WebAssembly or Service Worker."Recursive"——If a code runs on Chrome 60 but no Chrame 50, it's written as Chhome 50. Because part of the real user community is using the system version from years ago. CSS uses basic Flexbox layouts, and JavaScript uses ES5 syntax and has a Polyfilm covering key API missing.
Establish a knowledge base on compatibility of terminal equipment.
Instead of checking compatibility at zero point every time you go online, it is better to build up a database of end-compatibility knowledge in the system’s operations. Each time you find compatibility problems with a model of equipment in a given scenario, you record the model, the operating system version, the browser version, the specific phenomena, and solutions. Over time, this repository will be the most effective tool for team-checking compatibility issues.
The maintenance of this knowledge base does not require complex tools, and an online table or Wiki page is sufficient. Fields include: branding of equipment, system version, browser type and version, problem phenomenon description, impact (global/specific scenario), restoration program, repair state. With this library, new projects can quickly screen for known compatibility problems before they are online, avoiding falling repeatedly in the same pit.
Compatibility test strategy.
Compatibility tests that cover all equipment models completely are not possible and necessary. More practical approaches are based on operational data to select the test coverage from.WiFi certification systemThe top TOP 20 device model and operating system versions are extracted from the access log to ensure that they have been fully certified process tested. These 20 types of equipment usually cover more than 80% of the actual users.
The test is not just about the test."Can you pop the Portal page?"This point should cover the full authentication process: connect WiFi, trigger Portal, load pages, select authentication methods, input information, submit authentication, successfully jump through certification, and view web pages properly. There may be compatibility problems at each of these points, not just beginnings.——Testing is to be performed in a real deployment or simulation environment, as network delays, DNS configurations and HTTPS certification deployment patterns affect compatibility performance.
Device compatibility is not a problem that can be solved once and for all.——Each year, new mobile phone models are issued, new system versions are rolled out and new browser versions are upgraded. Compatibility is a continuous tracking and maintenance process. It is much more practical as part of daily transport than to consider it a one-time test before the project gets online.