Project

General

Profile

Bug #3689

Filter logs Input Validation Failure

Added by Mark Wharton over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
06/02/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:

Description

In
diag_logs_filter.php
entering a source or destination in the format 1.1.1.0/24 causes the below error to be repeated in the page output.

Warning: preg_match(): Unknown modifier '2' in /etc/inc/filter_log.inc on line 104 Warning: preg_match(): Unknown modifier '2' in /etc/inc/filter_log.inc on line 104 Warning: preg_match(): Unknown modifier '2' in /etc/inc/filter_log.inc on line 104 Warning: preg_match(): Unknown modifier '2' in /etc/inc/filter_log.inc on line 104 Warning: preg_match(): Unknown modifier '2' in /etc/inc/filter_log.inc on line 104

I Appreciate it's a expecting a regular expression, but I wouldn't expect an error rendered for an invalid regex.

Associated revisions

Revision c4107752 (diff)
Added by Phillip Davis over 4 years ago

Handle firewall log filter regex input better bug #3689

If the user inputs an invalid regex in any of the filter fields, then a page full of "warning" messages appear in the GUI, about whatever is invalid.
If for some reason the user wants to match a forward slash somewhere, then they have to realize to escape it, doing "\/" instead of just "/". Be nice to this special case, because the user does not necessarily know that "/" is being used as the delimiter in the preg_match call. Turn "/" into "\/" (when the "\" is not already put in by the user).
For other regex issues, suppress the warning output, using "@". When the user inputs some invalid garbage in a filter field, an empty filtered firewall log table will be displayed, rather than screens full of PHP warning output.

History

#1 Updated by Phillip Davis over 4 years ago

I submitted pull request https://github.com/pfsense/pfsense/pull/1222
This will be nice to this type of input, escaping the "/" to make the example become 1.1.1.0\/24 which is a valid regex.
The user can type all sorts of other invalid regex and get qa screen full of PHP warning messages from preg_match() calls. So I suppressed the warning text, that results in an empty table when the user enters an invalid regex.
Note for interest: When you enter stuff like 10.49.2.5 the dots are actually regex special characters that mean "match any single character". So this matches 10.49.215 for example (thus an address like 10.49.215.1 matches and appears in the output). In this GUI page, users normally mean the dots to be "real" and should enter 10\.49\.2\.5 to actually match the string "10.49.2.5". That is the designed and intended behavior, so no attempt to change or "help" with that. But I just noted it here for the benefit of random readers.

#2 Updated by Renato Botelho over 4 years ago

  • Status changed from New to Feedback
  • Target version set to 2.2
  • % Done changed from 0 to 100

Pull request merged

#3 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF