Hi everyone, and have a great day.
I’ve felt for a while that the captive system was lacking in a few areas, so I recently took the initiative to make some modifications.
The first change was to provide the terms of use in two languages—specifically, the local language and English.
The second was to enable clients without going through the web interface.
This allows devices that cannot enter a code via a web page—such as thermostats—to be enabled.
There is certainly room for improvement and refinement, but I’m open to collaboration with the goal of potentially making this an official feature.
I don’t use the Captive Portal myself, but your proposed addition of a Client option looks interesting, especially for IoT devices.
Which version of IPFire did you test it on?
If it works correctly on CU203, it might also fix the bug reported here:
I haven’t tested your patch myself, but as far as I understand, the bug concerns the portal display page.
It is possible that adding the client works because, in this case, the client does not need to be redirected to the portal home page (Terms or Coupon).
The only files that are supposed to be uploaded in the forum are image or pdf files.
The fact that the pdf file type can be used for getting around this limitation in discourse is being looked at to close this loophole.
Please create your own github or other sharing system to make your tarball available from.
I tested the modification on version 203, and manually adding clients works perfectly.
I haven’t yet modified the webpage where the coupon is entered for activation; I’ll do that later.
So, from what I gather, I believe the bug is still present.
As for the file, I’ve already deleted it; I’ll make sure to post the link in the coming days, as I think I’ll be able to work on it a bit more this week.
I apologize; I wasn’t aware that sharing code snippets wasn’t allowed. I knew sharing irrelevant material was prohibited, but I didn’t realize that applied to IPFire code.
I apologize again and will make sure to share the material via an external platform.
I think I’ve fixed the captive.cgi file;
I added a second language for the terms of use and the option to add a device without using a coupon.
The next file I’ll modify is captive/index.cgi, which is the one displayed when entering a coupon.
The files can be downloaded from this link.
Have you abandoned the “add client” feature ? It no longer appears.
Not with this file, anyway.
Its OK
Try it with the patch for /srv/web/ipfire/cgi-bin/captive/index.cgi I posted in the bug report.
https://bugzilla.ipfire.org/attachment.cgi?id=1721
Copy patch index.cgi.patch in /srv/web/ipfire/cgi-bin/captive/
And
cd /srv/web/ipfire/cgi-bin/captive
patch -p0 index.cgi < index.cgi.patch
Your file /srv/web/ipfire/html/captive/assets/UP.png is missing for Export coupon.
(I renamed ipfire.png)
I have a problem with Blue access if I enable both Green and Blue.
If I enable only Blue, it works.
But I don’t think the issue is on your end.
I’m not very familiar with the Captive Portal function; I don’t use it.
Have you tested Blue with both Green and Blue actived ?
Thanks, @pscar13, for pointing out the issue with the image; I had forgotten about a change I made this morning.
I added a new, mandatory SSID field in the setup section;
this field is required to generate the coupon PDF.
I’ve updated the file on my server with these changes.
If you find the work worthwhile, I’d like to ask you to start the validation process.
I tested it on my home device, using only the “Blue” network.
That is why the file included specific customizations (such as a logo and other elements).
I have some installations at educational institutions—the ones that requested these modifications—but they, too, use only the “Blue” network with the captive portal.
As for the validation process, I am not familiar with your specific procedure, but I am available to make any necessary adjustments and liaise with the validation staff.
I’m just another IPFire user, like you.
I run tests and participate in the community, but I’m not in IPFire developer team.
I think you could submit the feature request yourself.
To do that, the IPFire developers would need to be convinced that your use case could also benefit other users. Before submitting a request, it might be useful to see whether other Captive Portal users are interested in this feature as well.
You can find some information about feature requests here
Alternatively, if you have already implemented and testd your change, you could submit your patch:
Good luck!
I’ve finished the modifications and tested them on my home setup using multiple devices—both mobile and PC.
Everything worked flawlessly, and I didn’t encounter any errors or malfunctions.
The index.cgi file already includes the changes suggested by pscar13.
All files are available for download via the link I posted above.
I’m about to start the code validation process; I hope I don’t make any mistakes.
If I do, I apologize in advance, as I’m not very familiar with your procedure.
Don’t submit any patch with that change.
That is a workaround and not a fix. It is duplicating the same function in two places. Perfect to end up with future updates only getting done on one of the functions because it is forgotten that the same function exists in multiple places.
The fix is to find out why the escape function from header.pl is not working in index.cgi when it works in other .cgi pages and then correct that issue.
Okay @bonnietwin
it might be a good idea to start by validating the captive.cgi file.
The change I made to the /srv/web/ipfire/cgi-bin/captive/index.cgi file involves adding a second language and a different display layout—one I find more convenient for mobile devices. As I mentioned in a previous post, I am not familiar with your specific procedure, but I am fully available to assist the validation team; I would appreciate it if you could act as a liaison.
As mentioned by @pscar13 how to submit patches is covered in the IPFire documentation.
https://www.ipfire.org/docs/devel/submit-patches
If when you try that you have some difficulties then describe them and myself and others can then help with suggestions on how to overcome the difficulties.
I think it is good that you have come up with an improvement proposal but you really needs to be the one submitting it.
If another person acts as an intermediary then likely they will just have to pass on any questions to you as you have created the changes and know the background of them, which the intermediary won’t.
I, and others, would be more than willing to help with any difficulties you come across in creating the patch submission.
Okay, thanks @bonnietwin. As I mentioned, I’m not familiar with Git and have never used it.
I sent an email to the development mailing list as indicated in your guide.
Let’s see what comes of it.