SUMMARY recently the behavior of the networkmanager cp detection and login switched to using the distro specific url ".txt" file instead of using the trailing slash kde domain for cp login. using the distro url is fine for detection, but cp webservers generally dont rewrite non trailing slash urls for captive portal login. confirmed on fedora and arch. STEPS TO REPRODUCE 1. connect to captive portal network 2. attempt to login to the network using the networkmanager kde applet 3. view the distro specific .txt detection url 4. cry OBSERVED RESULT the connected network will fail to rewrite the url to the captive portal EXPECTED RESULT the dns and webserver in the captive portal will rewrite the domain and url to the captive portal
There doesn't seem to be anything we can really do about this: Using the configured URL is quite sensible, and if there's a problem with that, you'll need to report this: >cp webservers generally dont rewrite non trailing slash urls for captive portal login to the relevant distros. See discussion in https://invent.kde.org/plasma/plasma-nm/-/issues/8 and related merge requests.
(In reply to Oliver Beard from comment #1) > There doesn't seem to be anything we can really do about this: Using the > configured URL is quite sensible, and if there's a problem with that, you'll > need to report this: > > >cp webservers generally dont rewrite non trailing slash urls for captive portal login > > to the relevant distros. > > See discussion in https://invent.kde.org/plasma/plasma-nm/-/issues/8 and > related merge requests. To be clear: 1. the previous behavior had nm using the distro internet connection detection uri, which is a txt file containing a specific string, and when the user requested login to the cp, nm would call a kde domain that sucessfully would cause a redirect. 2. I was incorrect in saying that cp webservers cannot handle non directory names, but specifically will not generally handle .txt uris. html, htm, and mhtml all work fine. 3. the new behavior seems to break quite a few portals, including cisco/meraki, cox, and comcast. 4. this isnt really a problem with network detection, but with the ease of use of the nm applet, it is easily worked around by -not- using the nm-applet which, of course is non ideal. captive portal is admittedly kind of kludgey to begin with, which i assume is why this feature exists. I looked through the linked change, and it discusses the detection logic, and not the cp login functionality of the applet, if im not mistaken.
> To be clear: > 1. the previous behavior had nm using the distro internet connection > detection uri, which is a txt file containing a specific string, and when > the user requested login to the cp, nm would call a kde domain that > sucessfully would cause a redirect. this should read: 1. the previous behavior used the same kde domain uri that worked fine for internet connection detection and captive portal redirection. the new behavior uses the nm configurable uri, which fedora and arch provide as a .txt file uri in their respective domains, which breaks the captive portal redirection.
I understand. Specifically, this was changed in https://invent.kde.org/plasma/plasma-nm/-/merge_requests/391. I noticed that Arch uses https://ping.archlinux.org/nm-check.txt as the connectivity check URL (and so we use it for captive portal redirection), but also has https://ping.archlinux.org/ for captive portal detection — I wonder where it's used as it would work appropriately for both and not encounter this problem. I believe that using the distro's specified connectivity URL to redirect to a captive portal is appropriate (particularly because NM does not have any separate option). It is possible that we could, for redirection, use our own URL (there is reasoning to not do so in the aforementioned discussion) or try to remove any filename from the specified URL, but that could easily end up going to a 404 page. I don't think it's a great idea as some pages might have useful content for if they are accessed despite not being redirected to the captive portal. Please open bug reports with the distros. Feel free to reference this bug there. If they don't resolve this then we can look at doing so on our end. In the mean time, this bug has been set to NEEDSINFO.
Actually, stand by: BUG 460333 references using the default gateway. It would kill two birds with one stone if we did that instead.
> but also has https://ping.archlinux.org/ for captive portal detection — I if https is being used, the login redirection wont work in any case. unless im missing something here. there really isnt any issue with using the uri from the distribution in arch or fedora for captive portal detection/connectivity detection, and seems to be a Good Idea. The problem comes with using it in the applet login link. my brain, as broken as it may be, thinks that it should either be a seperate configurable link, or the http://kde.org/ or equivalent.