Bug #11268
closed
Cookie named ``id`` prevents some forms from being loaded or saved properly
100%
Description
If you have a cookie set with a name 'id' (any value), and you try to edit something, e.g. a firewall rule, the form fields are not properly filled in on the page - they seem to be set to the default values you'd get if you were creating a new rule.
(I have found this occurs in the wild, if you have a ports forwarded for both pfSense and a Synology NAS, and you log into both through the same hostname.)
Updated by Matthew Fearnley over 3 years ago
I've realised that the `id` entry in the session cookie is overriding the `?id=` URL parameter. E.g. setting it to 0 edits the first rule, setting it to 1 edits the second, etc.
In Chrome you can replicate this if you edit a port-forward (e.g. https://192.168.1.1/firewall_rules_edit.php?id=0), and go to Developer Tools, Application, Storage->Cookies.
Double-click a blank row in the Name column and type 'id', then can set the Value in a similar way.
(This also works for `dup` and perhaps other parameters.)
Updated by Matthew Fearnley over 1 year ago
Just to say this still affects current versions of pfSense - I've tested it in pfSense 23.05.1 Plus.
Cookie values still override the URL parameter.
It also seems to happen with other parameters - e.g. the `if` parameter on `/firewall_rules.php?if=wan`.
Updated by Jim Pingle 5 months ago
- Subject changed from Cookie named 'id' prevents Edit form fields being set properly to Cookie named ``id`` prevents some forms from being loaded or saved properly
- Status changed from New to Resolved
- Assignee set to Jim Pingle
- Target version set to 2.8.0
- % Done changed from 0 to 100
- Plus Target Version set to 25.03
This was fixed by 738f647c453a8995c6b411f91efb66c17a0d6c11 -- I could replicate it before that change but I can't replicate it after.
Updated by Jim Pingle 5 months ago
- Category changed from Web Interface to PHP Interpreter
- Release Notes set to Default