|
|
|
|
|
|
To configure a http server user must set its FQDN (Fully Qualified Domain Name) or internet address and decide if the server socket will be run as the secure one or not. It is done by marking the proper check box and putting a port number for the internet connection. User must choose a free port (i.e. not occupied by any other service) and higher than 1024 to run the optfinderML's service without the root privilege.
The optfinderML's server is set as a HTTP/1.1 server. Thus it is configured according to rules written in the RFC 2068.
When the optfinderML's server is started the Security Manager is set and the appropriate set of permissions is written in the Policy file. Only those program commands that are allowed by the Policy rules and are available for a program owner (default not root) can be execute otherwise the Security Exception is thrown.
If one decides to operate on the secure internet connection then a key pair (private and public) must be generated. It can be done with help of optfinderML that makes use of the java keytool command. The encryption tool stores keys together with the self-signed certificate in the external file called keystore (external - can be used independently of the program). Each time when the optfinderML is run in the server mode these objects must be loaded into program. When an user prefers to use a certificate signed by a CA (Certificate Authority) instead of the self-signed certificate the so-called signing certificate request can be generated by the optfinderML and then an user must send it to a CA. After obtaining signed certificate file it can be imported into existing keystore again with the help of optfinderML program. All data stored in the certificate as well as in all other necessary certificates (constituting a certificate chain), especially its fingerprints, should be printed out and checked before importing these objects into the external keystore as the trusted certificates. If the self-signed certificate is concidered to be sufficient for internet communication then it should be exported to the file and send to internet partners which may incorporated it to their keystores as a trusted certificate (after checking correctness of fingerprints!).
Establishing a secure internet connection protects data transfer. However, any unauthorized requests downloading and uploading data can be done (by anyone). That is why the optfinderML operating on a secure connection demands user authorization each time when it obtains a request. The basic authentication scheme is applied. It requires to add users to optfinderML database. It must be done by the person who administrates the optfinderML.
If server refuse to fulfill request for any reason then 403 (Forbidden) answer will be sent to the client.
In the case when so strong security protection is not necessary (when all internet communication is done only between known computers in a local net with no connection to the outside world) the insecure server socket can be used instead of the secure one. Then no user authorization is demanded.
Data download is available by the conditional GET method. Content can be gzip-encoded if is permitted by the Accept-Encoding request header field. A content sent out can be cached (as it is indicated by the response Cache-Control field having the values: private, must-revalidate). Validity of the content stored in the client's cache is checked on the basis of the If-None-Match (containing server's Etag field value) and If-Modified-Since (containing server's Last-Modified field value) request header fields. If a content was not modified then 304 (Not Modified) answer is sent (no content attached). It allows to recognize when a new system output was not generated and thus a client's request must be repeated in order to collect fresh entity.
Data upload is done by the POST method. The POST method requests the enclosed entity to be stored under the supplied URI. If the action performed by the POST method results in replacing of existing resource identified by a URI then detected server's response should be 200 (OK) and when a new resource is created on the origin server then the obtained response should be 201 (Created).
OptfinderML's server accepts the following Content-Types: text/plain, application/x-www-form-urlencoded and multipart/form-data.
The multipart/form-data type has been specifically defined for carrying form data suitable for processing via the POST request method, as described in RFC 1867.
One can use any http browser to communicate with the server or use any other http client program.
The scheme below-presented shows an example of communication between optfinderML HTTP server listening on the address 0.0.0.0:4443 where 4443 is a port number and a HTTP client's program. In the presented example client uses the server local address 0.0.0.0 in its requests, however, in the case of a remote client this server's address should be replaced by the server's FQDN or its external internet address. If the server uses a secure server socket then https request should be addressed otherwise http is the appropriate one. A client can send the POST request of above-listed content types at the very beginning or start from the GET request. The GET request results in the html page that is sent back and allows to upload data either as a file (i.e. as multipart/form-data) or a text enclosed in the text area (i.e. application/x-www-form-urlencoded). If user wishes to upload data as a file it can be gzip-encoded. After successful data transmission the message: Data has been uploaded. will be obtained by the client.
After successful data exchange the files containing environmental messages and payments should be found at the optfinderML/data directory whereas the system outputs should be transferred to an external resource representing environment.