[
https://issues.apache.org/jira/browse/VCL-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037757#comment-14037757
]
ASF subversion and git services commented on VCL-753:
-----------------------------------------------------
Commit 1604025 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1604025 ]
VCL-767
Added update_computer_private_ip_address subroutine to utils.pm. Renamed
update_computer_address to update_computer_public_ip_address and updated
calling subroutines in OS.pm.
VCL-753
Reworked enable_firewall_port and disable_firewall_port in Linux.pm. The
clean_iptables subroutine was not working correctly because the old code didn't
allow "any" to be passed for the scope.
Other
Alphabetized export list in utils.pm. Please put subroutine names in the
correct location when adding to this and reorder it if you rename a subroutine.
> Improve user connection checking and how firewall is locked down
> ----------------------------------------------------------------
>
> Key: VCL-753
> URL: https://issues.apache.org/jira/browse/VCL-753
> Project: VCL
> Issue Type: Improvement
> Components: database, vcld (backend), web gui (frontend)
> Affects Versions: 2.3.2
> Reporter: Andy Kurth
> Priority: Minor
> Fix For: 2.4
>
>
> The backend code which detects when a user is logged in and secures the
> firewall currently relies on the reservation.IPaddress column. This does not
> work correctly under some conditions if the IP address the user connects to
> the website differs from the IP address used to connect to the remote
> computer -- such as when a user connects to either the website or remote
> computer through a proxy.
> The backend code can be improved to temporarily open the firewall to any IP
> address when the request is in the reserved state or when the user clicks the
> Connect button from a different IP address. Once a connection is detected,
> the actual remote IP is retrieved from the OS and the firewall is locked down
> appropriately.
> This is a fairly complicated change and several things need to be changed in
> order for everything to work correctly.
> Database changes:
> Add changelog.reservationid column
> The changelog table will be used to record every IP address detected
> throughout a reservation. This table does not currently have a reservation
> ID column and there is no way to determine which reservation a changelog
> entry refers to -- only which request. This is needed for cluster requests
> in order to track which remote IP address was detected on which computer.
> The changelog.reservationid and changelog.remoteIP columns will have a unique
> key added in order to prevent an excessive number of rows from being added
> since a row would be added by every 'inuse' check.
> Add changelog.userid column
> This is needed for server/shared requests. If a user clicks the Connect
> button and another user is already connected, the backend code will quickly
> detect the connection from the existing user and lock the firewall down to
> that user before the user who recently clicked Connect can connect. A
> changelog.userid column will allow the backend to loop until a connection
> from a particular user is detected.
> Web front end changes:
> Whenever a user clicks Connect, add a changelog entry with the remoteIP and
> userid set. The changelog.reservationid column should be null due to cluster
> requests. Clicking Connect for a cluster request applies to all reservations
> in the cluster.
> Backend changes:
> Rework much of inuse.pm. Modify the OS module connection method and firewall
> subroutines as necessary.
> Whenever a connection is detected, add a row to changelog including the
> reservationid. If an existing row exists with the same
> reservationid/remoteIP values, update the timestamp.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
