@uggiz said in Captive Portal - Cron - Authentication issues:
its possible to get a "Quota used" message when the users gets logged out?
A browser getting a none solicited message from a web server with info ?
Noop. Never seen that before. Browers can connect to web server, get the file (page) they are looking for, and bye bye the connection.
It is possible to have a "logout" or "you are connected" browser windows open, and have that windows load some Jave stuff that questions the current status. if it was possible to get the "max allowed" and "current" bytes used .... but .....
See for yourself :
#!/usr/local/bin/php -q
<?php
require_once("/etc/inc/util.inc");
require_once("/etc/inc/functions.inc");
require_once("/etc/inc/captiveportal.inc");
/* Read in captive portal db */
/* Determine number of logged in users for all zones */
$count_cpusers = 0;
/* Is portal activated ? */
if (is_array($config['captiveportal']))
/* For every zone, do */
foreach ($config['captiveportal'] as $cpkey => $cp)
/* Sanity check */
if (is_array($config['captiveportal'][$cpkey]))
/* Is zone enabled ? */
if (array_key_exists('enable', $config['captiveportal'][$cpkey])) {
$cpzone = $cpkey;
/* Zone selected -> count users and add */
$cpdb = captiveportal_read_db();
foreach ($cpdb as $cpent) {
print_r($cpent);
echo date("m/d/Y H:i:s\n", $cpent[0]);
echo "---------------\n";
}
}
?>
Create a file called /root/cap.php and put the above content in it.
Now call it :
php -q /root/cap.php
and you see : no 'used' info is avaible in the pfSense portal session database.
The max quota is :
[traffic_quota] => 104857600
= 100 Mbytes in my test case = Ok.
Ok ... you could, on the web server java side, get the max and used info from these files directly.
Another info source is :
[image: 1713961353494-32e69f3b-9c5f-4239-9d3d-417955ee1941-image.png]
as the main log will be bombarded with these message (imho : they do not belong there - call me and I'll tell you how to ditch them).
edit :
Another way to have the user have page where you control the info :
Have seat-belts ? Put them on.
Read this close the initially irrelevant forum thread : captive portal is not working on mobiles
But in that forum thread I discovered something : the future of the captive portal ( ! )
It already exist, and you add it easily.
One condition : don't use KEA as your DHCP (portal ) server, you have to use ISC. because you have ti create a DHCP option for the HCP portal server.
Instructions are present in the forum thread.
You need to create one file (content of this file : see thread):
[image: 1713962350669-26a4bd49-d5c9-43a8-9383-374fd662abfe-image.png]
and now, if you have an Apple device, you can test : connect to the portal - and notice is connects faster - and when connected, tap on the SSID of the portal, and you'll see something new.
Open the new suggestd link called "Portal" and the text "This network proposes a portal page".
The page you now open - the "You are connected page" is the future "portal status page".
Btw : I've also see (real) Samsung devices using this new RFC 8910. Others devices : dono ...
Why I'm telling all this ?
The page you saw is created here :
/usr/local/captiveportal/index.php
That where uyour changes go with the info you want to show - if the user wants to see it (and if they know how to request the info, because again, this is "portalling" as it will be done in the future ...)
Btw : I've this method running for several month now. Works great. Doesn't interfere with the existing capture method at all, it completely bypasses it. The device will know where to go as soon as DHCP request has been answered. No more DNS hassle, web interception. Just plain KIS.
Read the RFC and you'll get the picture.
edit : sorry : I went way to far again / was ranting. Sorry.
