More text
This commit is contained in:
parent
92efceb034
commit
e2cb500f97
2 changed files with 15 additions and 5 deletions
|
@ -1,4 +1,6 @@
|
|||
\section{API} \label{api}
|
||||
\section{API}
|
||||
|
||||
\subsection{REST Endpoints} \label{api}
|
||||
|
||||
Managing the firewall rules can be done over a REST API\footnote{\href{https://www.ibm.com/cloud/learn/rest-apis}{What is a REST API}}. Available routes are following and can be retrieved by visiting the API (e.g. \verb|https://10.93.0.224:8080/api|) of the device.
|
||||
|
||||
|
@ -54,9 +56,13 @@ Available targets are \verb|REJECT, ACCEPT & DROP|
|
|||
|
||||
\newpage
|
||||
|
||||
\subsection{Authentication}
|
||||
\subsection{HTTPS} \label{https}
|
||||
|
||||
To authenticate the API uses basic auth. Communication is therefor encrypted to protect the process from eavesdropping. Setting the username and password is done via the constructor of the api class. To create the api class to setup the firewall rules a firewall class instance is needed.
|
||||
To connect to the esp over HTTPS (Hypertext Transfer Protocol Secure) the Webserver can be setup to use certificates that need to be included in the constructor as seen in section \ref{authentication}. This only works for the esp8266 with the Arduino library, can be added as an external library (\verb|esp32_https_server_combat|\footnote{\href{https://github.com/fhessel/esp32_https_server_compat}{https://github.com/fhessel/esp32\_https\_server\_compat}}) for the esp32 if needed.
|
||||
|
||||
\subsection{Authentication} \label{authentication}
|
||||
|
||||
To authenticate the API uses basic auth. Communication should therefore be encrypted to protect the process from eavesdropping. Example certificates for the esp8266 are included in the repository and encryption can be added to the esp32 as described in section \ref{https}. Setting the username and password is done via the constructor of the api class. To create the api class to setup the firewall rules a firewall class instance is needed.
|
||||
|
||||
\lstset{style=c++}
|
||||
\begin{lstlisting}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
\section{ESP Storage}
|
||||
\section{Storage}
|
||||
|
||||
To store the firewall rules there will be a class to handle storing and retrieving of the currently active rules. For each board there is a library available that will handle most of the work for us.
|
||||
To store the firewall rules there will be a class to handle storing and retrieving of the currently active rules. For each board there is a library available that will handle most of the work.
|
||||
|
||||
\subsection{esp8266}
|
||||
|
||||
|
@ -26,3 +26,7 @@ To use the individual library with the firewall rules the firewall can be extend
|
|||
void store_all_firewall_rules(firewall_rule_t *rule_head);
|
||||
void store_firewall_rule(firewall_rule_t *rule_ptr);
|
||||
\end{lstlisting}
|
||||
|
||||
\subsection{Space Allocation}
|
||||
|
||||
Each rule will get exactly the space it needs (\verb|firewall_rule_t|). Therefore a maximum of rules of \textbf{15} is specified in the constructor of the class. At the lowest storage space, there will be 8 bit for the current amount of rules to keep track how many rules need to be restored at power up.
|
Reference in a new issue