You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2014/03/12 17:59:43 UTC

[jira] [Commented] (VCL-753) Improve user connection checking and how firewall is locked down

    [ https://issues.apache.org/jira/browse/VCL-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931995#comment-13931995 ] 

ASF subversion and git services commented on VCL-753:
-----------------------------------------------------

Commit 1576819 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1576819 ]

VCL-753
Added changelog.reservationid and changelog.userid columns to vcl.sql and update-vcl.sql.

VCL-560
Fixed typo in update-vcl.sql regarding the vmprofile table.

Other
Added reservation.imageid and reservation.imagerevisionid constraints to reservation table.

> 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)