On-rev setup

[Peter TB Brett]

On 2015-05-25 19:47, Ethan Lish wrote:
> Hello,
> My goal is to create a captive server which can only be accessed via
> our authorized LiveCode client.  
> This would me that, when an unauthorized client attempts connection;-
> the application will be distributed via the store- access via our
> authorized LiveCode client to server resources are logged &
> permitted - our authorized LiveCode client appropriately protects
> embedded URL, accounts & passwords - access via an unauthorized client
> to server resources via HTTP/HTTPS are exception logged, denied access
> & redirected to a ‘load our application’ page- access via an
> unauthorized client to server resources via mySQL are exception logged
> & denied access
> The above is fairly straight forward on a private closed network, but
> presents a challenge when hosting on on-rev.com or in the cloud.
> I would be interested if anyone has a product or white paper  or
> recommended strategy for the above.

Hi Ethan,

Firstly, only allow connections over HTTPS.  Redirect all HTTP requests 
to the corresponding HTTPS URL.  HTTPS will protect *all* connection 
information apart from the address of the server from snooping.  That 
includes all form data, all HTTP headers, all request URIs, etc.

Next, allocate a hard-to-guess token (e.g. a UUID) to each version of 
your app.  When your app sends *any* request to the server, specify the 
token in the "Authorization" HTTP header, e.g.

     Authorization: token 098dd825-34a3-4158-97bf-24a82dc10a4b

Deny all HTTPS requests that do not specify a permitted token.  Usually 
you would deny the request with a "403 Forbidden" error.

Ideally, you would provide each user with a unique token.  For example, 
you could provide a service endpoint https://example.org/login, which 
would permit access with the app's token, and accept a username and 
password.  If the username and password are valid, the response would be 
"200 OK" and the body of the page would be a new session UUID for that 
user.  That UUID could then be used as a token for accessing other 
resources.

In summary:

- Allow access only over HTTPS
- Deny all requests which lack a valid token in the headers
- Consider a scheme that allocates per-user/per-device tokens

                                               Peter

-- 
Dr Peter Brett <peter.brett at livecode.com>
LiveCode Engine Development Team