Random GUI Bug deleting rules.
-
2.2.2-Release (AMD64)
Built 13 Apr 20:10:22I've long suspected a bug deleting rules plus other weird things, and might have figured out the circumstances to watch out for.
Firstly I'll run multiple instances of Firefox, generally one instance of FF for each monitor as was the case last night, but sometimes might run two or more instances of FF on a monitor. I also have open multiple tabs in each instances of FF as can be see in this two monitor screen shot posted here https://forum.pfsense.org/index.php?topic=94548.0.
Now as would be expected I'd be doing stuff on one FF tab like creating some rules for one interface which is visible on one tab, then I might switch to another FF tab make some rule changes or reload the filter for Status:System Logs: Firewall as was happening last night.
Anyway, I had a rule disappear when I clicked on the Edit or Add-new-rule-based-on-this-rule icon (cant remember which if honest), but then hit the browser back button as I didnt want to edit/add a new rule.
Now when I clicked the back button it returned to previous page Firewall :Rules (corresponding interface tab selected) which lists all the rules for the interface and thats when I noticed the rule had disappeared.
What I've also noticed is if you repeat the above steps as I've done this morning, when hitting the back button in FF, normally and most of the time you get a FF warning message saying Document Expired, The document is no longer available blah blah do you want to try again, where by clicking try again will popup a new message box with the options to Resend or Cancel. Hit Resend and you can reload the Firewall:Rules page opened on the correct interface tab.
When FF throws the message say the document is no longer available your rule wont disappear.
Its when FF doesnt throw the message and returns you to the previous Firewall :Rules (corresponding interface tab selected) that you should expect the rule to disappear.
I've tried all sorts of combinations again this morning but no joy repeating the disappearing rule but I figured if I flag this up others might also be aware of the problem so could be extra vigilant if they work in a similar way to myself as some prefer command line etc.
Thinking about it, I've got a couple of Windows programs here which I might also be able to use to help track down the problem but I'll need to rehash some of the code first before I can use it to keep track of what I do in web browsers, but these might at least keep track of all my steps which can make it easier to determine if this is a reproducible bug or a random bugs which I suspect the latter is the case.
Anyway just a heads up and a FWIW.
If anyone else has any suggestions as to why rules were disappearing let us know.
TIA.
-
Some more to add to further quantify the circumstances.
100% I did not delete the rule as thats pops up with a are you sure type of message and I couldnt be bothered to scroll down to click save or cancel hence why I hit the back button, being lazy I didnt have to move the mouse as far or operate the scroll bars/mouse wheel.
When I say "I've long suspected a bug" this is since beta testing. Was the php server element upgraded in 2.2? If so this could be something to do with that element of the pfsense system.
Reason I'm so sure the rule was deleted was it was the 1st rule at the top of the list for the interface affected and was disabled, originally I was going to [edit]
undeleteenable [edit] it but then backed out of it.Further tests.
I've duplicated the 1st/top rule on an interface but made it disabled and moved it to the top. I have then opened up another tab in Firefox opened up on the same interface tab for the firewall rules so I have in effect two tabs in FF open showing the same thing.I can delete the disabled rule from one of the FF tabs (lets call it FFTab1), click Apply Changes and as expected it still shows in the other FF tab (FFTab2) the now deleted rule, I say expected as web browsers are essentially stateless.
If I then click add-a-new-rule-based-on-this rule for what is now the deleted disabled rule from FFTab2 it shows the enabled rule that is now technically first in the list. Perhaps to improve the user experience, it might be possible to throw a warning saying this is not the rule you hoped to duplicate or something to that effect as this is one of the weaknesses of the GUI experience. However if I hit the back button I dont return to the list but get the Document Expired webpage which is not what I got last night, I just returned to the list.
If I duplicate the first rule on the interface again, make it disabled and position it to the top of the list, refresh both FF tabs so both shows the disabled rule is top of the list and then delete the disabled rule in FFTab2, click apply and then switch to FFtab1 and proceed to edit the disabled rule but then hit the browser back button I return to the list as I experienced last night not Document Expired is seen but the disabled rule has rightly disappeared from the list of rules as well.
This could have been what I experienced last night which would make it not a random bug but a user error which I could be guilty of although I'm fairly but not 100% I didnt have somehow the same Interface rules tab showing in two FF tabs. Its possible.
In the further tests Ive done today since the first post, it doesnt matter if you click Apply Changes or not when deleting rules in the above two example walk throughs.
But this little exercise has prompted another question, what do other people do for checking for any changes to their rules/fw's ideally in an automated way which can flag up changes made between checks? I'm just trying to reduce the incidence of human error ideally as well as nefarious behaviour from bad actors which might show up but not always when considering Schoolmontana and other PBD's. ;)
-
Perhaps I'm just more paranoid about browser behaviour, but I've never considered it "safe" to use the "Back" button with pfSense.
I use Firefox almost exclusively and open many tabs w/pfSense to keep track of various things but whenever I'm making a rule add/change/delete I make sure I only move "forward" through the browser process. The closest I get to violating that rule is to "batch" changes by not clicking "Apply Updates" until I've made all my changes.
I don't expect the "Back" button will let me "undo" anything.I don't know if it's even reasonable to expect pfSense to survive or operate correctly if you're trying to step backward through it's WebGUI.
I can just imagine too many ways the experience could go badly wrong…..
Just my $.02
-
I'd agree with much of what you say if I was editing a rule, but I'm not 100% sure I had two FF tabs open on the same interface at the same time last night and like you I certainly would not expect to be able to undo anything by hitting the back button, its purely for navigation only. However having written my own webservers attached to various databases along with the stateless "headache" of browsers compared to apps and the javascript employed to force reloads when a user hits the back button which then prompts a reload, maybe like I've said above, could the user experience be improved a bit?
Until I recode these windows apps I've got to record everything I do in the browser I cant be 100% its a random bug or user error. If its user error I'll hold my hands up to that but if its not perhaps a bit of extra vigilance is useful considering this https://forum.pfsense.org/index.php?topic=94162.0 is something I've hit upon as well which might be sorted in 2.2.3.
All I can say is theres some odd things happening in my systems even when they have been taken down, bioses updated, spin diskswiped before OS's installed and yet these odd things going wrong like my ssd HD pwd which is set using the bios gets changed and its not been forgotten as I've had the pwd written down. Saying that Persistant Back Doors (PBD) are a reality in this world along with other tricks so ultimately what is going on in my system is anyone's guess atm. :)