Created attachment 1721 [details] index.cgi.patch Since correction bug 13996. The Captive Portal page is no longer displaying on CU203 unstable I'm getting an ERR_CONNECTION_TIMED_OUT error in Microsoft Edge, and in Firefox, I'm redirected to the IPFire homepage. This happens with or without accents in the forms. The issue appears to be caused by requiring header.pl from index.cgi. After removing require "${General::swroot}/header.pl", adding use Encode, and copying only the needed escape function into index.cgi, the captive portal page works again. This suggests that header.pl introduces a side effect affecting captive portal output, encoding, or HTTP response handling. Here is the patch I tested. OK
Still present on CU203 Test - Development Build: master/8024c29c
And so? We have hundreds of bugs open. This is really not how you encourage anyone to look at this.
Sorry ... It's not a priority for me either.
I just tried it with Core-Update 203 Development Build: master/8024c29c with the French language selected and the Captive Portal displayed with no problems. I was able to enable the Captive Portal on Blue and then create an unlimited coupon. So I can't reproduce your issue. In earlier versions of CU203, did you do any manual modifications of any of the files to fix the problem prior to the changes available in Core-Update 203 Development Build: master/8024c29c. My CU203 Testing system was a full released version of CU202 that was then updated to CU203 Testing.
Okay, You know this function better than I do. Since I don't use it, I probably didn't do the right test, sorry. If it's OK with you, you can close the bug report.
Thank you Adolf for testing. I will close this bug and if it comes back, we can always re-open.
This is being re-opened as another user has reported the issue on the forum. I have also realised that misunderstood the issue being reported. I had thought it was the captive portal cgi page not being shown, which was what I had tested. I now realise that it was the login page itself not getting shown on the client PC. I have tested that and can confirm that the browser tries to connect to the IPFire system but it timesout.
Reply to Adolf Belka on the community forum https://community.ipfire.org/t/problems-with-captive-portal-and-203/16106/6?u=pscar13 > Your patch creates a completely new escape function used only in that location rather than using the one in the IPFire defined functions. I agree that the escape function should be moved elsewhere. However, it is currently defined in header.pl, and using header.pl is precisely what causes the captive portal page to be hidden/not displayed correctly. I think this function should be moved to general-functions.pl, but that would require refactoring all the CGI pages that currently rely on it being defined in header.pl.
Hello @all, The issue easily can be re-produced, by enabling the captive portal and trying to authenticate -> Only a white page is shown and in some cases the client connection timed out with a hint that the page on port 444 via http could not be opened. This as pscar13 already identified correctly mainly depends on the recently include of the header.pl perl library at the captive/index.cgi page, which is responsible for those authentication mechanism on client side. The header.pl library does a check on runtime if it is called by the server and via https and if not it automatically redirects to the https port. See: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/cfgroot/header.pl;h=05f67fc0d2d76d2a9564ab13d9bce8e6574851be;hb=HEAD#l99 As this can not work in this situation there are multiple possible ways to fix this issue: 1.) Drop the check in the header.pl ( Sadly I do not know exactly, why this check exists, but I think for some kind of safety and security reasons... ) 2.) Extend those check to allow white-listing some sub-pages which can be accessed via http. 3.) Move the "escape" function to the general-functions library ( This needs to touch all CGI pages which rely on this ) 4.) Create a copy of the "escape" function in the captive/index.cgi page and remove the include of the header.pl ( This of course is code duplication and makes maintaining in the future harder... ) 5.) ? - May I have missed something... Best regards, -Stefan
Thanks Stefan, That is indeed the explanation I gave yesterday: https://community.ipfire.org/t/modified-captive-system/16141/25?u=pscar13 The patch I proposed three months ago (described above) addresses point 4 that you mentioned. I also tested point 3; propagating `escape()` in `general-functions.pl` requires modifying 99 files, all of which would then need to be re-tested. I have no further opinion on proposals 1 and 2. But you would certainly know better than I do which one is best.