Bug #10359
closed
Require State Filter setting breaks filter rule link to associated states
Added by Jens Groh over 4 years ago.
Updated over 4 years ago.
Affected Version:
2.4.4-p3
Affected Architecture:
All
Description
If one configures
System > General Setup
- Require State Filter -> yes (enabled checkbox)
that's a great way to stop browsers (like firefox) to crash or load infinitely while opening "Diagnostics > State" on a busy firewall.
We had to set this as on our busy datacenter cluster there were so many state that most browsers were going down while trying to load the state table page unfiltered.
But: with the above option set, the cross-linking of states belonging to filter rules is no longer working:
- enable "Require State Filter"
- save
- go to "Firewall > Rules"
- click on the States in front of a busy firewall rule that you want to check
- you are redirected to diag_dump_states.php but the page thinks that your call is "unfiltered" therefore not showing anything
This behavior can be found up until the latest 2.4.5 RCs.
Is it possible to "rewrite" the call from the filter rules page, that it shows the states for that rule but leave the general "require state filter" in place so nobody accidentally crashes its browser entering diag_dump_states.php without filtering? Perhaps filling out the corresponding fields when jumping to the page? I know, no game-breaking bug, but a little annoying one as it robs us of a valid diagnostic/debugging tool and linking to states in firewall rules becomes obsolete.
Thanks,
Jens
Firewall rules page uses $_REQUEST['ruleid'], but diag_dump_states.php checks only for $_POST['filter'] and requirestatefilter option.
This PR adds check for $_REQUEST['ruleid']:
https://github.com/pfsense/pfsense/pull/4241
- Status changed from New to Pull Request Review
- Status changed from Pull Request Review to Feedback
- Assignee set to Renato Botelho
- Target version set to 2.5.0
- % Done changed from 0 to 100
PR has been merged. Thanks!
works as expected on 2.5.0.a.20200321.2101
- Status changed from Feedback to Resolved
Cherry-picked and manually installed "b9ab356250f68213fe36b6cba1758feee581ac83" via System Patches to 2.4.5-RC
Working as expected (tested with and without, reverted and applied again).
Currently running an upgrade to latest 2.4.5-RC and will try again.
Re-tested on latest 2.4.5-RC, still working as expected.
Just as a short question: I suppose after following the quick release of 2.4.5 that fix didn't go into 2.4.5, too? Just asking so I can have it rolled out via System Patches instead? Or are there plans for a 2.4.5-p1 somewhere? :)
Jens Groh wrote:
Just as a short question: I suppose after following the quick release of 2.4.5 that fix didn't go into 2.4.5, too?
Just asking so I can have it rolled out via System Patches instead?
Yes, for 2.4.5 you need to use System Patches for this fix.
Or are there plans for a 2.4.5-p1 somewhere? :)
Stay tuned for Netgate news.
- Status changed from Resolved to Feedback
- Target version changed from 2.5.0 to 2.4.5-p1
- Status changed from Feedback to Resolved
Works as expected now. Filtered states are displayed when following the link from the rules list.
Also available in: Atom
PDF