Project

General

Profile

Actions

Bug #13694

closed

Strange behavior when disabling a firewall rule while anoter is simultaneosly in Edit mode

Added by Chris W over 1 year ago. Updated over 1 year ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

It appears this is regardless of interface. WAN and floating are from the original ticket so they're used here as an example.

1. On the WAN interface, create two arbitrary rules that you can easily recognize:
- Allow any to destination 1.1.1.1, description "ONE"
- Allow any to destination 2.2.2.2, description "TWO"

2. Click the pencil icon to edit WAN rule TWO.

3. Now in a second browser tab or window go to Firewall > Rules > Floating. Click on "Add Below" and manually copy the TWO rule information into a new a floating rule with:
- (X)Quick, Interface Any, Direction In.
- click Save.

4. Now in the tab or window still with the WAN interface's TWO rule in edit mode:

- check (X) Disable this rule
- click Save

This takes you back to the WAN ruleset.

Result:
1) Now two copies of the TWO rule exist on the WAN interface: one disabled, one below it enabled.
2) Rule TWO on the WAN has vanished.

A few notes:
- Apply Changes doesn't need to be selected, and of course until it is, nothing shows up in Firewall-Generated Rulesets.txt of a status output archive.
- If you instead edit the ONE rule, then any other rule directly above isn't removed/overwritten, but it's still duplicated (see 2nd screenshot).


Files

Actions #1

Updated by Chris W over 1 year ago

  • Private changed from No to Yes
Actions #2

Updated by Chris W over 1 year ago

  • Private changed from Yes to No
Actions #4

Updated by Lev Prokofev over 1 year ago

Tested on
23.01-DEVELOPMENT (amd64)
built on Fri Nov 18 06:04:48 UTC 2022
FreeBSD 14.0-CURRENT

In step "4" after "Save" I get the following error messages:

Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in /usr/local/www/firewall_rules_edit.php:1057 Stack trace: #0 /usr/local/www/firewall_rules_edit.php(1057): strtolower(Array) #1 {main} thrown in /usr/local/www/firewall_rules_edit.php on line 1057 PHP ERROR: Type: 1, File: /usr/local/www/firewall_rules_edit.php, Line: 1057, Message: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in /usr/local/www/firewall_rules_edit.php:1057 Stack trace: #0 /usr/local/www/firewall_rules_edit.php(1057): strtolower(Array) #1 {main} thrown

Actions #5

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug

While this could be handled better, it's not a bug but a design flaw in how any area handles items by index number instead of a unique identifier. Any time two tabs or users are open on different items, if one action changes the order of items in the configuration, the other tab will be holding open the "wrong" entry.

There are other architectural changes that would need to be made to work around this, but that is more of a long-term redesign/planning issue not a bug.

Actions

Also available in: Atom PDF