Many sites using the WiFi network real name certification system have encountered a situation where the backstage of the system is running well, AP online, but since users have access to WiFi, Portal's authentication page is not popping up or when it comes out is messy, or if the mobile phone endpoint does not respond. Such problems are often unrepeated in the testing environment, but they are reflected in the production environment by five-fifths.
A few typical reasons why Portal's page couldn't be shot.
After the user connection to WiFi, which requires authentication, the equipment initiates a HTTP detection request (usually a specific URL), and if it receives an unexpected 200 response, the device will judge."Network needs authentication", and then automatically pops out the Portal page. The process seems simple but there are several points that fail in actual deployment.
The first common problem is that HTTP detection was interrupted by the re-direction of HTTPs. Some WiFi network real name certification systems were configured to redirect all HTTP traffic to Portal pages of HTTPS. But iOS and Andre's requests for detection were pure HTTP, and if 301/302 were received to jump to HTTPs, which the certificate itself signed, the equipment would reject the response, arguing that there was a problem with the network, and that the Portal page had no chance of popup.
The second problem is that the domain name on Portal does not appear on DNS White List. Before users complete authentication, the system repositions all DNS requests to local resolution servers and releases only authentic domain names. If Portal uses a JS library or photo resource on CDN, these external domain names ' DNS requests are discarded, half loaded and are stuck, showing a blank or completely confused style. This issue is not easy to detect during the testing phase because testers usually go directly to the Intranet and DNS is not hijacked.
The third reason is that IPs for certification services are not released without authentication. Portal pages themselves need to be loaded from the authentication server, and if an IP for a authentication server is also strategically intercepted, requests cannot be sent at all. This is common in newer configurations, when several of the multiple IPs for domain names have been added to the white list but they are not released, causing occasional loading failures.
The reason Portal page styles are malfunctioning on the phone
Many Portal pages of the WiFi network real name certification system were made a few years ago and designed primarily for PC browsers. When the cell phone is open, either the font is too small to see, or the layout spilles out both sides of the screen, or the buttons are too small. These issues are essentially not responsive design, but they are fixed to the supplier code, which is not directly addressed at the transport level.
Even more problematic is the fact that Portal uses an iframe frame or JavaScript framework, which is not supported by a user ' s internal browser or has too old versions. The iOS built-in browser (CNA Brodser) is essentially a lightweight WebView with limited support for JavaScript, and some ES6 grammatically or async/await will be misreported directly and pages are overtaken. The situation on Andre is more complex, with different brands of ROM treating Captive Portal differently, either by requiring user clicks to open a bomb notice, or by direct floating windows and inconsistent behaviour.
Some of the teams tried to add one to Portal."If page display is not normal, use the browser to access XXX manually"The method is too demanding for users, and few people actually do it. More people react to it."WiFi's broken."Then go find IT.
The certification was successful, but it's still not online.
Another common problem: users have completed mobile phone number verification on Portal page and the system is ejected"Authentication successful"But it's not going to be online or it's gonna break in a few minutes.
One is that the session timeout is too short. The WiFi network real name authentication system assigns a session to each authentic user, during which traffic is released normally and after which it needs recertification. If the time is set at 30 minutes, the user will be kicked out for a while and requires recertification. For users who do not often see their mobile phones, this experience is bad and it makes sense."WiFi's always breaking up.". This parameter should be set according to the use of a scenario, which is recommended for no less than eight hours and can be adjusted to the operation strategy in public spaces.
Another situation is the migration of MAC addresses. When users are connected to different APs under the same SSID, if they re-activate the authentication process while travelling between APs, the user suddenly breaks off the web for a few seconds. This is particularly evident in the case of such APs covering overlapping areas in conference rooms or corridors. The solution is to enable the certification service to recognize users as having passed the authentication and not to re-enter the Portal process.
Another problem is that the post-certification strategy fails. After authentication has been successful, the system should send instructions to AP or AAC to release access rights for its counterpart. If this instruction has not arrived successfully because of a delay in the network or loss of messages, the certification status is successful at the back of the system but the user is actually intercepted and only waits for the next recertification or manual refreshing. Such questions need to be checked at the log level, which is difficult to locate by user description alone.
SMS's not getting through to some operators.
If WiFi's real name authentication system is a text message-certification code, the stability of the SMS channel is a hidden risk. The main problem is two: one is delay in the SMS channel itself, with peak hours likely to be delayed by more than 30 seconds, and users click repeatedly to re-remit during waiting, and as a result receive a large number of authenticating codes that they do not know which to use; and the other is when SMS is identified by operators as marketing SMS or SMS service providers being blacklisted, resulting in some cell numbers being uncollected.
When the latter happens, IT usually last knows because users are saying that"I can't get a text message."and"WiFi's broken."It seems different, but it is actually a different manifestation of the same problem.
What about the main operator on Portal?
This is a often overlooked compliance detail. The Portal certification page requires the display of information about the network operator, including unit names and contact details. This requirement has grey areas for actual implementation, many sites have only one Logo, with no complete operating entity information.
Also, the privacy policy statement on Portal is becoming increasingly important. Users submit a mobile phone number for real name authentication, which in effect requires a clear information and user confirmation link to authorize operators to collect personal information.
How many system logs and user authentication records are connected?
Portal certification is only the first step. The three types of data that need to be linked to authentication records, web logs, and session records in order to restore a complete chain of behaviour at retroactive origin. The problem is that these three categories often have different modules, sometimes inconsistent fields, sometimes time-touching, leading to extensive data cleansing when linking queries.
When deploying the WiFi network real name certification system, it is recommended that storage locations, formatting and correlation fields for these categories be identified in advance, and that data not be found to be out of place until there is a genuine need for traceability. This is a function that should be validated at the testing stage, rather than leaving it to the production environment to replace.