PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) solution. Boasting an impressive feature set including a captive-portal for registration and remediation, centralized wired and wireless management, powerful BYOD management options, 802.1X support, layer-2 isolation of problematic devices; PacketFence can be used to effectively secure networks small to very large heterogeneous networks.
Describe the bug
Configured a portal with two modules: sponsor (email) and provisioning (dpsk) for an open SSID to show a DPSK after a sponsor confirmed the registration of a new device/user.
a new device connects to the open ssid
the device asks the user to login to use the network
user gets redirected to portal
portal shows a form field asking for the users email
a pre-defined (module) sponsor gets an email asking to confirm the user
portal page on users device updates to show a SSID to connect to and a DPSK
This works nice and smoothly.
To test the workflow again I …
made the device forget the protected SSID and disabled wifi
deleted the device node from packetfence (web-interface)
deleted the sponsored user from packetfence (web-interface)
enabled wifi on my testing device and connected to the open SSID
When opening the portal page it shows me without asking for the users email the DPSK and the protected SSID to connect to. No activation by a sponsor is needed.
At the moment I open the portal page the second time the log shows …
… and a new user entry appears with id=chris@doma.in and no sponsor and no email, but with a newly created DPSK.
Looking around I found that information about the portal session still is stored in the redis cache that seems to be used.
Delting the session data for the httpd.portal from redis solves the problem and the device can start over testing the portal.
Expected behavior
If user and node are not known to packetfence anymore and the device connects newly to the open SSID the portal workflow should start over with the form field to let the user enter their email and then waiting for activation by the sponsor.
Smartphone (please complete the following information):
Describe the bug Configured a portal with two modules: sponsor (email) and provisioning (dpsk) for an open SSID to show a DPSK after a sponsor confirmed the registration of a new device/user.
This works nice and smoothly.
To test the workflow again I …
When opening the portal page it shows me without asking for the users email the DPSK and the protected SSID to connect to. No activation by a sponsor is needed.
At the moment I open the portal page the second time the log shows …
… and a new user entry appears with
id=chris@doma.in
and no sponsor and no email, but with a newly created DPSK.Looking around I found that information about the portal session still is stored in the redis cache that seems to be used.
Delting the session data for the httpd.portal from redis solves the problem and the device can start over testing the portal.
Expected behavior If user and node are not known to packetfence anymore and the device connects newly to the open SSID the portal workflow should start over with the form field to let the user enter their email and then waiting for activation by the sponsor.
Smartphone (please complete the following information):