| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
By:
Separating the source and destination onChange functions
Preventing the mask selector from being automatically updated if it is disabled
Simplifying the auto mask JavaScript
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
$_POST['ipprotocol'] needs a bit more sanitising. Some conditions test if it's a zero-length string, other conditions test if it's set/unset.
Moreover ipprotocol is used to test and set valid values on other fields, so an invalid value on $_POST['ipprotocol'] has knock-on effects for other field validation that aren't trapped (although an invalid ipprotocol itself, is trapped), and a few places test it redundantly (for example if !$input_errors[] then ipprotocol must have been both set and valid, so no need to test isset()).
A few other minor form fields should be sanity-checked before being relied upon as valid. Needs checking if any are missed.
Last, $_POST['interface'] isn't validated, but I'm not sure what the correct validation expression would be for it, and the correct handling if !input_errors (see also the FIXME at line ~ 780)
|
| |
| |
| |
| | |
Fixes #7356
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Phil Davis <phil.davis@inf.org>
|
|/ / |
|
| |
| |
| |
| | |
functions - Firewall
|
| |
| |
| |
| | |
guiconfig.php display_top_tabs supports "usepost" as an optional 4th argument
|
|\ \ |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These bits were not translating.
Line 1406 could possibly be like:
```
$group = new Form_Group($name . ' ' . gettext('Port Range'));
```
But then that assumes that in every target language the translation of "Source" or "Destination" can be put in front of the translation of "Port Range".
So I have given the translators both full phrases to do what they like with.
|
| | |
|
|/ |
|
|
|
|
| |
Moved setHelpText() to helpers file
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Seems to fix https://redmine.pfsense.org/issues/7057
But I have not looked underneath the hood - just copied the way other hidden fields are done in that code.
|
|\ \ |
|
| |/
| |
| | |
icmptype is a comma-separated list in the config. When attempting to save, the array in $_POST['icmptype'] needs to be put into this format in $pconfig in case there are input errors and the user-entered data need to be re-displayed for correction.
|
|\ \ |
|
| |/
| |
| | |
The 'helpmsg' here is already translated with gettext() when the 'helpmsg' array entries are set up, so IMHO there is no need to attempt translation again.
|
|/ |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
@jim-p wanted this split out from PR 3159 as it wasn't related to that PR.
Puts "any" at the logical place people look for it (top of list not 2/3 down it at random) while ensuring that for new rules default is tcp and extra ports etc fields are visible.
|
|\ \
| |/
|/| |
|
| |
| |
| | |
Safari doesn't seem to have editing issues (or else they very quickly fixed it). Removed all white spaces and re-entered, hopefully this fixes any incorrect extraneous characters that existed? If not you'll have to let me know where exactly they are.
|
| | |
|
| |
| |
| | |
Will pu in separate PR afterwards as requested
|
| |
| |
| | |
Code doesn't seem to check that IP protocol is valid (IPv4/6/4+6) or report via $input_errors[] if not. Simple fix. Only spotted recently. Should be fixed whatever else?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
@jim-p commented on the PR that:
> This change is unwarranted. The protocol default should remain TCP, it is set that way on purpose (otherwise people get confused by the lack of port options being visible). It's also not relevant to the other changes being made on this PR.
An alternate fix for jim-p's point. this only affects creating new rules and I take the point. I found this a much better fix (AFAICS). It seems to resolve all issues neatly.
Proposed fix: leave "any" at the top of the list as that's the logical place people almost always look for it if they want it, _but set the default proto to tcp for new rules_ so that ports and other expected items are displayed by default too. After all, the default protocol is only relevant for showing tcp and ports fields, when a new blank rule is created (obvious: if the rule exists it would display the protocol in the existing rule).
@jim-p can you try this as a fix, and see if it would be acceptable for resolving your point?
|
| |
| |
| |
| |
| | |
https://github.com/pfsense/pfsense/pull/3139#pullrequestreview-156718
I ended up having to remove the select element and re-create it (along with the options) in order to get around what appears to be a bug in Safari.
|
| |
| |
| |
| |
| | |
1. On creating a new rule, $pconfig['ipprotocol'] is undefined, rather than defaults to what is seen in GUI (IPv4). Form generation logic for the ICMPType list box can't rely on a good value. It was fixed late here and missed when copying changes to Github. Very likely responsible for above issue by @rbgarga . Please confirm if this fixes it for you. On the off-chance that it still doesn't, can you let me know if _editing an existing rule_ works, which will help.
2. Reordering #proto options affects JS logic, because JS uses index() to identify which protocol is selected. Generally I feel this isn't the best practice, if the value is what matters then it's better and easier to review, if the code references the value itself (.val()) not the position in the list which could change (.index()). That said, I should have spotted this anyway.
|
| | |
|
| |
| |
| | |
See main PR for details
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1) Add alias and host types to Form_IpAddress with the appropriate hover
text.
2) Remove the patterns - the UI of those is not so effective anyway, so
leave the validation of input to the back end.
3) Update uses of Form_IpAddress to use the appropriate Alias or Host
type as needed.
4) Remove explicit setPattern() from those uses of Form_IpAddress.
|
|/ / |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the user:
a) Edit a firewall rule
b) Select "single host or alias"
c) Enter an invalid IP address that is not an alias
d) Press "Save"
The error is displayed "1.2.3.999 is not a valid source IP address or alias"
But note that the rule type dropdown has changed to "Network".
In the case where there is $_POST data, we do not want to try and deduce the srctype or dsttype from the IP address in the src or dst field, because the value of that field could be the very invalid data that the user entered. We want to maintain the value of srctype or dsttype that the user selected and let them correct the error they made in typing the actual IP address.
|
| | |
| | |
| | |
| | | |
First of many
|
| | |
| | |
| | |
| | | |
This reverts commit 9444a281f051e11d5456cc37b2a3f56fc8a7bc33.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Expand the types of Form_IpAddress so that the caller can specify
exactly what combination of IPv4, IPv6 address and alias is allowed for
the field.
Set the appropriate input pattern and hover help text.
Only toLowercase() the entered value if it has a ":" in it - i.e. it
looks like it is intended to be an IPv6 address (rather than an IPv4 or
an alias name).
|
| | |
|