Kupiki-Hotspot-Script
Kupiki-Hotspot-Script copied to clipboard
Allow users to register themselves
Add a register button in the portal
I can help you with this. But this enhancement would be better done after we have a new hotspot manager like daloradius.
I've read the source code of daloradius, in hopes that I can make it compatible with freeradius 3, but the code is so old, it does not conform to new standards. It would be better to start from scratch.
You mentioned you are doing something similar but with nodejs, if I remember correctly. In that case, I was thinking, we could use nodejs to serve the portal too. So we can remove nginx, and put them all together in nodejs, we don't have to deal with php in this case.
here's my folder structure so far.
admin
node_modules
portal
package.json
pihotspot.js
then calling node pihotspot.js
would fire up the server at the IP and Port of choice.
on mine it will go at 192.168.10.1
with port 80
for the portal. <Raspberry Pi IP>/admin
for the radius admin.
I have disabled nginx.
seems to work nicely on my test.
You can have a look at the admin repo. There is a script that works on debian and raspbian to install the admin frontend. It serves an api in node and there we can add a register part. I already have it implemented. It creates the records within radcheck table The problem is that installing all will take a long time as npm is not really fast on a pi
back to main topic..
I'm just curious why would you let users register themselves? How can this be useful? I mean, we create a captive portal using freeradius+chilli so that we can manage users connected to our network... If we let the user register themselves, then it's like having no captive portal?
Can you please add more description to this?
I guess that's like a public hotspot. In my case i Don't need the feature but in some circumstances maybe that could be usefull. That's something that would be optional with a parameter within the admin frontend
One way it may be useful to let users register themselves would be to get people to sign up to your mailing list.
So when someone connects to your captive portal, they enter their email address and then one of two things happen:
- Customer auto signed in
- Customer sent an email, once verified the email address then the customer can login.
Something like this can be useful for small cafe's where they want to offer something but build a mailing list from people who know about the cafe and are interested in it (not just randomly scraped addresses).
I have seen a few companies do this, would be a useful option.
The current portal is great in a business for guest access or a hotel though.
@versavius i take the point for next change and improvements (the list is longer day after day :)
Hey no problem, i could tell you have alot on your plate already, it was just a useful suggestion to automate things to make things easier for really non-IT people :)
Thanks for listening though :)
Opening again the point. I'm currently looking for chilli_proxy usage like in the embedded mini portal. Any help is welcome on that ;)
Hello, any improvements on this?
I remember this post is the first time I thought about my software. haha.
I think kupiki can do some upgrades. But I'm not sure if the changes will be acceptable.
I went only with nodejs and coova chilli. No nginx, no mysql, no php, no freeradius. here's a video with voucher https://www.facebook.com/MavisPisoWifiSolutions/videos/353494265202403/ You can see it on 1:10 time in the video.
But my software is so big now. It can do more than just vouchers. Here's another video with me using it: https://www.facebook.com/MavisPisoWifiSolutions/videos/2284367325134710/
Maybe I will create another software cutting all other features if that can help kupiki. You can check more images here: https://mavispisowifisolutions.com/piso-wifi/
The registration process is now finished and should be integrated in Kupiki soon. It requires a rewrite of the Portal to add that part in the tool Kupiki will continue with freeradius and mysql to keep attributes functions including bandwith limitation, hours, etc. to not rewrite all
Very nice.
But actually, attributes functions including bandwidth limitation, hours, etc are in coova chilli. freeradius is just the authentication and mysql is where freeradius keep track of everything.
But the one that controls bandwidth limitations, hours, device disconnections, etc is coova chilli.
Yes, rewriting kupiki will be a big change. So I guess not.
Waiting to see how you did the registration. I will check it when it comes out.
There is a repo published in the kupiki organization for the portal backend in case you want to have a look on it
This feature could be really interesting! Where is the repo? I would like to test and be helpful.
Best regards, Rosario
That's the default behavior in the latest version of the script
OK, but do I need to go on another page? Because my login page didn't show anything about registration
Go to /usr/share/nginx/portal/js and update the active value from false to true in the register property. Refresh your browser
I will try. Thank you. I suppose that the option VARIABLE specified on pihotspot.sh is not enough tough.
@0iras0r : yes you are right, i have to correct that
@pihomeserver I tried yesterday by modifying /usr/share/nginx/portal/js/configuration.json and set registration 'true' instead of 'false' as you suggested. It seems to work fine. Thanks a lot. I will try to adjust code to make 'allow registration' actually works when you set it before installation. ;-)
Good news. We should add an extra command in the installation script to sed the configuration file from false to true
Hi,
I considering using your script to open an internet wifi access in the library where I work and this possibility to let the user register themselve is really great. The best for us would have been to just have a page where user just have to accept sort of "term of service" without having to register (with mac adress log to respect the french law), but, it a very nice thing to let them register themselve, what potentially let them use the service from outside of the building when the library is closed.
You can use the register part of the portal to generate users (replace input by generator) to create something similar to a vouncher. You can create users in a default group that has some restrictions on time, volumes, etc. based on your requirements
Ok, thanks for your answer, i'll try to see that when I'll have some time (what a rare and precious thing is the time ! ;).