PF13.1: after portal finished, user/node deleted, portal doesn't start over

[chri2]

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 …

Mai 16 11:52:54 paketzaun httpd.portal-docker-wrapper[71518]: httpd.portal(15) ERROR: [mac:10:2c:6b:xx:xx:xx] Database query failed with non retryable error: Cannot add or update a child row: a foreign key constraint fails (`pf`.`node`, CONSTRAINT `0_57` FOREIGN KEY (`pid`) REFERENCES `person` (`pid`) ON DELETE CASCADE ON UPDATE CASCADE) (errno: 1452) [INSERT INTO `node` ( `autoreg`, `bandwidth_balance`, `bypass_acls`, `bypass_role_id`, `bypass_vlan`, `category_id`, `computername`, `detect_date`, `device_class`, `device_manufacturer`, `device_score`, `device_type`, `device_version`, `dhcp6_enterprise`, `dhcp6_fingerprint`, `dhcp_fingerprint`, `dhcp_vendor`, `last_arp`, `last_dhcp`, `last_seen`, `mac`, `machine_account`, `notes`, `pid`, `regdate`, `sessionid`, `status`, `time_balance`, `unregdate`, `user_agent`, `voip`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? ) ON DUPLICATE KEY UPDATE `category_id` = ?, `pid` = ?, `unregdate` = ?]{no, NULL, NULL, NULL, , 2, pureos, 2024-05-16 11:43:43, Phone, Tablet or Wearable, AMPAK Technology, Inc., 67, reMarkable Paper Tablet, , , , 1,2,6,12,15,26,28,121,3,33,40,41,42,119,249,252,17, , 0000-00-00 00:00:00, 2024-05-16 11:52:44, 2024-05-16 11:52:54, 10:2c:6b:xx:xx:xx, NULL, , [email protected], 0000-00-00 00:00:00, , unreg, NULL, 2024-05-16 12:08:32, Mozilla/5.0 (X11; Linux aarch64; rv:109.0) Gecko/20100101 Firefox/115.0, no, 2, [email protected], 2024-05-16 12:08:32} (pf::dal::db_execute)
Mai 16 11:52:54 paketzaun httpd.portal-docker-wrapper[71518]: httpd.portal(15) DEBUG: [mac:10:2c:6b:xx:xx:xx] disconnecting db (pf::db::db_disconnect)
Mai 16 11:52:54 paketzaun httpd.portal-docker-wrapper[71518]: httpd.portal(15) ERROR: [mac:10:2c:6b:xx:xx:xx] Unable to modify node '10:2c:6b:xx:xx:xx (pf::node::node_modify)

… and a new user entry appears with [email protected] 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):

• Device: Librem5
• OS: PureOS Byzantium (Debian Bullseye)
• Browser Firefox-ESR