Problem description
In the introduction of wifidog implementation of the Internet authentication function, there are 2 problems: HTTPS redirection and select detection, the former does not require users to access 80 port, the latter resulting in low efficiency. For the user experience, HTTPS cannot be actively redirected very intolerable. In my UC browser, the recommended website has a Sina, it is HTTPS, each click to die where, very embarrassed, of course, from the address bar to choose the Blog Park, is also white screen.
Problem handling
This article deals with HTTPS redirection only, and the select issue is not currently covered. began to want to modify in the WiFiDog code, mainly listening to 80 and 443 ports, processing process also according to the existing 80-port message flow process. However, after grasping the packet, the browser still displays "error" even if the router correctly replies to the redirected page. Want to also, HTTPS messages are encrypted, directly borrow HTTP messages to reply, should not pass. Later on the Internet to find some information, found in the server-side HTTP and HTTPS forced redirection of the configuration is very valuable reference. By first let the service side of the Nginx support SSL, to it to create a key and CRT files that do not require a password, and modify the Nginx configuration, to confirm that the server itself supports HTTPS access. Finally, on the router or gateway, redirect 443 messages to the authentication server.
This way, when the browser uses HTTPS, it is no longer white screen, but the authentication page on the authentication server. Of course, the browser will prompt this station certificate is illegal, whether to continue access (experience or bad). This needs to get the CRT file issued by the certification authority, and then to see if this message will disappear.
For now, there is a hint, better than white screen.
For records only, for the next perfect.
HTTPS redirection in WiFi authentication