[
https://issues.apache.org/jira/browse/VCL-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032844#comment-14032844
]
ASF subversion and git services commented on VCL-753:
-----------------------------------------------------
Commit 1602979 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1602979 ]
VCL-702
Reworked new.pm::reserve_computer to not include OS-specific code. Moved some
of the old functionality to a new OS.pm::reserve subroutine. Updated reserve
subroutine in Linux.pm and Windows.pm.
Removed new.pm::confirm_public_ip_address. The functionality exists in
OS.pm::update_public_ip_address.
VCL-753
Added OS.pm::get_connect_method_remote_ip_addresses. Added Linux.pm:
get_user_remote_ip_addresses, get_port_connection_info.
VCL-564
Added OS.pm::run_scripts, which was formerly in Windows.pm. This isn't called
from anywhere yet.
Added $SOURCE_CONFIGURATION_DIRECTORY variable to Linux.pm.
VCL-253
Added Windows.pm::check_rdp_port_configuration. This is called from
Windows.pm::post_load. If the port number for the RDP connect method doesn't
match the registry it is configured.
> 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)
