----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128707/#review98920 -----------------------------------------------------------
>From my perspective using www.kde.org for the browser part of the process is >fine. Using it to detect whether or not you are behind a captive portal (which >afaik is handled by NetworkManager and the URL for doing that is set by >distributions). Please note that the index of www.kde.org is not static - it is dynamic content, generated via PHP. - Ben Cooksley On Sept. 6, 2016, 7:37 a.m., Jan Grulich wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128707/ > ----------------------------------------------------------- > > (Updated Sept. 6, 2016, 7:37 a.m.) > > > Review request for Network Management, Plasma, KDE Usability, and Lamarque > Souza. > > > Bugs: 365417 > http://bugs.kde.org/show_bug.cgi?id=365417 > > > Repository: plasma-nm > > > Description > ------- > > Adds portal monitor to our kded module, which checks NetworkManager > connectivity. If the value gets changed to NM_CONNECTIVITY_PORTAL (means we > are behind a captive portal), then we open a QWebEngineView trying to load > "http://kde.org"; page which is supposed to be redirected to the captive > portal page. Once user logs in and url changes, we re-check the connectivity > again and close the web view if we are no longer behind the captive portal. > > > Diffs > ----- > > CMakeLists.txt a27c1f2 > kded/CMakeLists.txt 1f0613e > kded/portalmonitor.h PRE-CREATION > kded/portalmonitor.cpp PRE-CREATION > kded/service.cpp 18ffd41 > > Diff: https://git.reviewboard.kde.org/r/128707/diff/ > > > Testing > ------- > > Tested with three different captive portals and it worked perfectly. > > > Thanks, > > Jan Grulich > >
