<commit_before>% Nginx as a reverse proxy

\section{Nginx as a Reverse Proxy}
\label{sec:reverse_proxy}

The demo system is a distributed architecture of isolated units which communicate with an HTTP-based API. Thanks to this API these
units do not need to know which is the location in the network of the rest of other units. As explained in Sec. \ref{sec:methodology} this
does not only hide the complexity of the system from the outside, but from the inside too.

To implement the requests routing with API to the corresponding modules, a \emph{reverse proxy} is used. A reverse proxy receives a
request, analyses it, and forwards it to the designated server using a table. It is the inverse operation which is performed by a
classic proxy. In the IPOL demo system the nginx reverse proxy is used.

Nginx is also used to redirect incoming requests to the corresponding port and address of the machine where the module is 
running on. It uses the configuration found in the \emph{sites-available} directory to create a routing table which allows to deliver to the right endpoint.
Another of its main functions is to serve static files and to expose them on a public location (say, a URL). The Control Panel is a Django web application which puts its static files in a specific directory. 
The system serves these static files directly with Nginx, without the need to reach directly Django. Nginx also serves the static files of demo system as for example HTML pages, CSS, and the static data from the blobs and archive modules.

\subsection{Private demos}
The IPOL system provides private demos which require authentication using a username and password. The system decides if a demo is private or public depending on its ID. To implement this mechanism, Nginx checks the argument ID from the URL looking for a numeric pattern, checks this number, redirects to the authorization page and depending on the company name it will contrast the information provided by the user against this company credentials. If it is successful the system will grant access, otherwise an error will be shown. The following configuration example checks the ID of the
demo and redirects the authentication process if the pattern matches.

\begin{lstlisting}[language=Bash]
location /demo/clientApp/ {
        expires 24h;
        if ($args ~ ".*id=33333001\d*") {
            error_page 418 = @CompanyNamePasswd;
            return 418;
        }
        alias  /resource_folder/;
    }
    
location @CompanyNamePasswd {
	auth_basic "Restricted";
	auth_basic_user_file /etc/nginx/.passwd/companyName;
        proxy_pass  http://127.0.0.1:81/$request_uri;
    }
 \end{lstlisting}

With this declaration Nginx uses a special code (418) to redirect to another location (@CompanyNamePasswd) wich is unique for each 
compay with private demos in the system. This way each company has it's own security credentials. For each company there exists a file
(/etc/nginx/.passwd/companyName) containing a user and password hash pair to evaluate the given authentication data in the server.

A second server only the local machine can access is the one that evaluates this authentication so no one else can skip authentication.
In case of a successful verification this second server grants access to the demo page serving the static files, otherwise returns an
error page.

\begin{lstlisting}
server {
        allow 172.16.17.32;
        allow 127.0.0.1;
        deny all;

        listen *:81;<commit_msg>[doc/system] Errata and review corrections<commit_after>% Nginx as a reverse proxy

\section{Nginx as a Reverse Proxy}
\label{sec:reverse_proxy}

The demo system is a distributed architecture of isolated units which communicate with an HTTP-based API. Thanks to this API these
units do not need to know which is the location in the network of the rest of other units. As explained in Sec. \ref{sec:methodology} this
does not only hide the complexity of the system from the outside, but from the inside too.

To implement the requests routing with API to the corresponding modules, a \emph{reverse proxy} is used. A reverse proxy receives a
request, analyses it, and forwards it to the designated server using a table. It is the inverse operation which is performed by a
classic proxy. In the IPOL demo system the nginx reverse proxy is used.

Nginx is also used to redirect incoming requests to the corresponding port and address of the machine where the module is 
running on. It uses the configuration found in the \emph{sites-available} directory to create a routing table which allows to deliver to the right endpoint.
Another of its main functions is to serve static files and to expose them on a public location (say, a URL). The Control Panel is a Django web application which puts its static files in a specific directory. 
The system serves these static files directly with Nginx, without the need to reach directly Django. Nginx also serves the static files of demo system as for example HTML pages, CSS, and the static data from the blobs and archive modules.

\subsection{Private demos}
The IPOL system provides private demos which require authentication using a username and password. The system decides if a demo is private or public depending on its ID. To implement this mechanism, Nginx checks the argument ID from the URL looking for a numeric pattern, checks this number, redirects to the authorization page and depending on the company name it will contrast the information provided by the user against this company credentials. If it is successful the system will grant access, otherwise an error will be shown. The following configuration example checks the ID of the
demo and redirects the authentication process if the pattern matches.

\begin{lstlisting}[language=Bash]
location /demo/clientApp/ {
        expires 24h;
        if ($args ~ ".*id=33333001\d*") {
            error_page 418 = @CompanyNamePasswd;
            return 418;
        }
        alias  /resource_folder/;
    }
    
location @CompanyNamePasswd {
	auth_basic "Restricted";
	auth_basic_user_file /etc/nginx/.passwd/companyName;
        proxy_pass  http://127.0.0.1:81/$request_uri;
    }
 \end{lstlisting}

With this declaration Nginx uses a special code (418) to redirect to another location (@CompanyNamePasswd) which is unique for each 
company with private demos in the system. This way each company has its own username/password. For each company there exists a file
({\tt /etc/nginx/.passwd/companyName}) containing a username and password hash pair to evaluate the given authentication data in the server.

A second server that can only be accessed by the local machine evaluates this authentication in order to avoid that a user passes over the authentication step and goes directly to the final page. In case of a successful verification this second server grants access to the demo page that serves the static files or otherwise it redirects to an error page.

An example of this second server:
\begin{lstlisting}
server {
        allow 172.16.17.32;
        allow 127.0.0.1;
        deny all;

        listen *:81;
{'fraction_non_alphanumeric': 0.04339861913484571, 'fraction_numerical': 0.012399605467098774, 'mean_word_length': 3.9394572025052192, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 6, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3070537', 'n_tokens_mistral': 1776, 'n_tokens_neox': 1672, 'n_words': 1034}