At the moment the user can answer "yes" to most of the questions, but then later code only checks if the answer is "y". Thus you can type in "yes" in some places, have it accepted, but actually the negative action is taken. That is weird and will mess up people who try typing a whole string starting with "y".
With this change it makes the user type one of "y", "yes", "n", "no". When they type 1 of those, it is turned into either "y" or "n". Then the existing implementation logic all works as expected.
Hopefully this is the "final" version that fixes the behavior of the (y/n) questions.
I also included the bit at 296-297 which adds the CIDR bit-count range to the prompt, so the user can see exactly what input is valid/expected there.
Redmine issue #4100
Currently this allows the user to input any number for the CIDR. I happened to try 44 for an IPv4 CIDR when playing.
This fixes that little bug - I think it is good to commit that first/separately so it can be identified apart from the other (y/n) checking/handling I am working on. Better to have separate commits for distinct bugs.
I had a 2.1.5 system that I was wondering why the dashboard always said it could not check for updates. I discovered it had "Use an unofficial server for firmware upgrades" checked, but the "Base URL" field was empty.
That can easily be checked with input validation - might as well catch dumb things like that.
I thought about making it parse the string to see if it seemed like a "valid" URL. But so many strings seem like valid URLs:
var_dump(parse_url("abc"));
array(1) {
["path"]=>
string(3) "abc"
}
It seemed a bit pointless to bother - if the user puts something in then hope that it might point to something some day.
- Remove redundant declaration of $icmptypes and move it to a common
place (filter.inc)
- Add missing ICMP types for v4
- Add ICMPv6 types
- Adjust javascripts to show correct options depending of IP Protocol
- Hide ICMP type selection when protocol is IPv4+v6
It fixes#3389
- When interface is 'lo0', strpos returns 0, that is erroneously
considered false (boolean) on the test. Be more strict on strpos return
to avoid skiping lo0 ip aliases during sync.
Alternate version of https://github.com/pfsense/pfsense/pull/1376
This version retains the is_array() checks and then only does the count() if the is_array() is true.
Take whichever version you like.
Forum: https://forum.pfsense.org/index.php?topic=85187.msg467438#msg467438
The bold is specified literally in gateways.widget.php for the gateway IP box, so we need to send it bold from here also when providing an update.
Because this now uses a "/" in the string (to terminate the bold) have to choose another delimiter between the status text and status color - picked "^" because I can't think where it will appear elsewhere in the real data.
This whole string of stuff that is returned by getstats.php back to the browser is a long string with a bunch of delimiters inside delimiters already (vertical bar separated fields, inside that comma-separated fields...) and is already subject to stuff going wrong if any of the real text in the fields contains a vertical bar or comma or... Not about to try to re-engineer all that right now!
Recent commit 9ea554ee5c added testing of the return status of console_configure_dhcpd() - this let a user effectively abort from doing anything if they have answered "y" to prompt_for_enable_dhcp_server() and are being asked for the start and end of the range, and then decide they do not want to proceed.
However, even when they gave good answers, status 0 was being returned. This prevented changes ever being implemented.
Redmine: https://redmine.pfsense.org/issues/4080
The fix is to return 1 at the routine end, when all is good and the code should proceed.
