Red Hat Bugzilla – Bug 1011050
Missing port range validation for custom ports settings
Last modified: 2014-09-03 00:57:17 EDT
Port validation for socket binding screens is broken again. I am able to set i (where $i > 65535) as port number. Only screen where this validation still works is Socket Binding (standalone) screen.
I have added port range validation for all of the sockets that were missing it.
One thing to note: There are several ports with default values of 0. These obviously will not pass validation. Are there better default values that could be assigned to these so that the user isn't forced to manually change them?
See this commit for details:
Ports with assigned value 0 aren't used at all.
eg. modcluster is using only multicast-port.
<socket-binding name="modcluster" port="0" multicast-address="188.8.131.52" multicast-port="23364"/>
We can either remove them completely (each port with value 0 shouldn't be configurable and should be left to 0 by default), disable them, or left them to 0 as it is now.
Disabling the non-user-configurable ports in the socket panels would require an extension to izpack, and leaving them with a default value of '0' would require removing their validation which means the user would be able to set them to any arbitrary value.
So instead, I have removed them from their respective panels.
Details in the commit:
Changed how the post install jobs connect to server (domain does not use port offset, while standalone does). Specifying a port offset no longer leads to failure in the post-install panel.
See commit for details:
The post-install panel currently doesn't support user-specified management ports for all of the various configurations of the standalone server (regular, ha, full). So manually changing the management port for the ha and full configurations will lead to failure in the post-install. This support will added by the next ER.
Please disregard previous comment about port offsets. It was meant for https://bugzilla.redhat.com/show_bug.cgi?id=1009421.
Please move all BZs ready for verification to ON_QA once the target milestone was released, thanks.
Verified on EAP 6.2.0.ER3