Bug #10359
closedRequire State Filter setting breaks filter rule link to associated states
100%
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
Updated by Viktor Gurov over 4 years ago
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
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
Updated by Renato Botelho over 4 years ago
- 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!
Updated by Viktor Gurov over 4 years ago
works as expected on 2.5.0.a.20200321.2101
Updated by Viktor Gurov over 4 years ago
- Status changed from Feedback to Resolved
Updated by Jens Groh over 4 years ago
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.
Updated by Jens Groh over 4 years ago
Re-tested on latest 2.4.5-RC, still working as expected.
Updated by Jens Groh over 4 years ago
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? :)
Updated by Viktor Gurov over 4 years ago
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.
Updated by Jim Pingle over 4 years ago
- Status changed from Resolved to Feedback
- Target version changed from 2.5.0 to 2.4.5-p1
Updated by Jim Pingle over 4 years ago
- Status changed from Feedback to Resolved
Works as expected now. Filtered states are displayed when following the link from the rules list.