If the Advanced Settings are saved before any other IPsec is set up then $config['ipsec'] can be just the empty string. As a result you can get:
a) If you select some debug settings then those are not saved. The code to save those settings was only executed when $config['ipsec'] was already an array. Actually the code already did the necessary "if isset() then unset()" stuuf. So I just took the the "if is_array()" away from the code block.
b) Some potential unset() can go wrong with errors like:
Fatal error: Cannot unset string offsets in /usr/local/www/vpn_ipsec_settings.php on line 168
This is corrected by adding more "if (isset())" checks.
Fixes Redmine #4865
The GUI should show descriptions according to what's selected from the dropdown, but currently does not for URL Table (IPs) and URL Table (Ports) type of aliases.
It originally coped with things like cuau1 cuau1.1
Then I made it cope with things like cuau1 cuau11 but it stopped working for cuau1.1
This one copes with:
cuau1
cuau1.1
cuau1.11
cuau11
cuau11.1
cuau11.11
That should allow for all sorts of reasonable device name files without matching other stuff in /dev (like cuau1.init cuau1.lock) that we need to ignore.
Please think if I have covered the bases here.
Removing the "." that was in {,.[0-9]} allows it to match /dev/cuau10 and onward.
I added lots of comments on the glob expression, because the format of the glob expression is not the same as an ordinary regex.
If there is an input error then the edit page is redrawn showing the
input errors. The HTTP_REFERER becomes the current page, rather than the
true original referer. Then if you click Cancel the current page is just
redrawn.
This change makes the code remember the original referer, so if the user
enters some invalid data, presses Save, reads the input error messages
then presses Cancel they are taken back out to the original page - the
same as if Cancel was used before Save.
When adding a Virtual Server, if you press Save with blank fields, the validation does not show. That was because the switch statement selecting the fields to validate had wrong case values. Actually the "mode" here is locked to "redirect_mode" (later code to allow the mode to be selected by the user is commented out - not implemented.
I fixed the reqdfieldsn array also for relay_mode case, even though it is never used. It looked dodgy the way it was.
If you go to Interfaces, assign, PPPs, press "+" to add an entry, then press Save without entering anything then you get a warning about the foreach() here.
The is_array() check fixes it.
Make the required fields be correct and match thier text names, which should each have their own gettext() cal so as to build a proper array at line 81. Basically it was all broken and the errors displayed when field/s were left empty were rubbish.
If you click "+" to add an alias, then press Save without entering anything, you get:
Warning: Invalid argument supplied for foreach() in /usr/local/www/firewall_aliases_edit.php on line 402
as well as the various messages related to $input_errors.
This change ensures that $input_addresses array always exists (even if it has no real entries) so that the foreach() warning does not happen.
If you open firewall_aliases_import and enter just an invalid Alias Name (e.g. a$b) and press save or press save with all fields empty, then the screen redraws but the input error(s) is not displayed.
This fixes it.
1) A disabled gateway can always be enabled - no extra validation
needed.
2) When disabling an enabled gateway, check to see that the gateway is
not used in any gateway group or enabled static route (similar tests to
what is already checked before deleting a gateway).
3) A static route can always be disabled - no extra checks needed.
4) When enabling a static route, check that the selected gateway is
enabled - you cannot have a static route enabled on a disabled gateway.
5) Do the address family cross-check between static route and gateway
even when the static route is disabled - we do not want to save
mismatched IP address families in any case.
This covers all the cases I can see to ensure that the enable/disable
status combinations of Gateways and Static Routes is always valid.
When enabling or disabling a route by using the enable/disable button on the Routes page, the destination network was not being put in the config change description, although the code intended it to be there.
This fixes it.
