Popup dialog replaced with toast notification for success. Although the
reason behind this bug is yet not understood because the dialog should
have been accepted by the corresponding method in the PO, as it has done
before, replacing it with a toast notification should nevertheless
remove the possibility of it happening again.
locked IPs are fetched after being compared with the permission for each
IP. Those that fail the permission permission check are removed from the
result of the fetch operation. This removal was previously happening in
an iterable.forEach method, removing elements from inside this method
caused a ConcurrentModificationException, so forEach usage was replaced
with an iterator that safely allows removals based on cursor position.
Locked IPs were previously not treated as SecuredSecurityType, but
rather their actions were treated as separate ServerAction instances
with the object in question remaining the server. To maintain permission
granularity at the IP address level, Locked IP addresses have been made
HasPermissions object in SecuredSecurityType with DefaultActions READ
and DELETE serving as get and unlock method permissions respectively
that can now be treated as the object wildcard of permission triples.
A method was exposed from UserManagementWriteService for bulk unlocking
a selection of users by their username. An 'extra' property was added to
successInfo class to return usernames without disturbing GWT
serialization. corresponding test is also written.
In SecurityServiceImpl, the
UserManagementException.PASSWORD_AUTHENTICATION_CURRENTLY_LOCKED_FOR_USER
property is used to return an error message with a constant referrable
string that is checked against a condition elsewhere in the code. I had
caused issues in the code by replacing this referenced string with a
custom error message without accounting for its usage elsewhere, causing
faults. This has been reversed.
in the IP Blocklist panel, the unlock button was added at an index
position. this was not necessary, but cascaded the issue that when the
refresh button was not added at 0, inserting at index 1 caused errors
cascading upto LocalServer.
the refresh button did not need to be added before the commit separately
because it was composed by a buttonPanel.addAction method that did both
object creation and addition to the panel together before commit
c10f6027a3, and after that commit was
created by a Button constructor.
use DefaultActions.READ and .DELETE instead of creating altogether new
ones in SecuredDomainType
allow unlocking for those with the roles admin or server admin, or those
with the DELETE permission on the respective ip blocklist domain type.
fail2ban didn't extend the lock when a lock already existed on said IP. this was remedied. the test failed because selenium was looking for a component using the driver, so from the head of the tree, instead of from the webelement, which was at a specific lower point in the element tree and thus is unaffected by selenium IDs being similar. the findElement is now done from a method on the webelement.
System properties were being read from the config file previously, but not set using system.setproperty as they are expected by the selenium package later. This fixes that by setting them before control is handed over to selenium
Sohaib Baig