1) Only attempt to delete the oldusername if it actually was non-empty - at the moment errors are logged in the system log when adding a new user, because the code was trying to delete the user name "".
2) Call local_user_set() first to create (change, whatever) the user record. This makes the user record exist for a new user. Then call local_user_set_groups() to sort out what groups the user should be in or not in. The existing code would fail to add a new user to the specified group/s because local_user_set_groups() was called too early, before the user actually existed.
Typical system log errors from the old code:
Mar 18 17:10:31 php-fpm[9542]: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing.
Mar 18 17:10:31 php-fpm[9542]: /system_usermanager.php: The command '/usr/sbin/pw groupmod admins -g 1999 -M '0,2003,2006,2008' 2>&1' returned exit code '67', the output was 'pw: user `2008' does not exist'
From looking at the code history, I think this has been this way for a long time, not a new bug at all.
Discussed in forum: https://forum.pfsense.org/index.php?topic=90700.msg501766#msg501766
At the moment you can make a VLAN with tag 0. The input validation does not catch it because when $_POST['tag'] = "0" that evaluates to false by PHP.
Always make the checks on 'tag' value whenever the 'tag' key is set at all. If the (required) 'tag' key is not set, then that is already checked for by do_input_validation().
Button - make sure we correctly escape link & text
Select - with multiple selected values; look at keys instead of values
StaticText - switch Input::__construct args
Textarea - introduce
Example: LAN IP 10.0.1.1/24 OPT1 IP 10.0.2.1/24
Rules with SRC or DST LANnet correctly have 10.0.0.0/24 (the subnet base address) in /tmp/rules.debug
Rules with SRC or DST OPT1net have 10.0.2.1/24 (the OPT1 IP address with OPT1 net mask) in /tmp/rules.debug
It still works (I think) because actually 10.0.2.1/24 and 10.0.2.0/24 interpreted as a subnet still describes the same set of IP addresses, but it looks odd, as reported by: https://forum.pfsense.org/index.php?topic=90096.msg498474#msg498474
Same issue with IPv6 for OPT1net rules.
This fixes the rule generation to that OPT1net uses the base subnet address in the rule, in the same way that LANnet and WANnet does.
This just looks wrong. But I guess the code path never comes through here because function readline() already exists in the environment of this script.
With this change it looks to me like the way it is intended to be, based
on what was done to get_possible_listen_ips()
Please review and check if this is what was intended for the code. With
this change it should make the returned $sourceips array be in a
consistent format the same way as get_possible_listen_ips()
This is a fix for code that was only committed in master. So at this
time the fix is only needed in master.
Looking at where this is nested inside various if statements, I do not think this error did too much harm - only to the $mac['descr'] - in this particular code flow $username is not used for important stuff after this point.
