Continue writig thesis
This commit is contained in:
@ -20,8 +20,8 @@ running in the \texttt{solvable} Docker container and frontend
|
||||
components written in Angular.
|
||||
For instance the built-in code editor requires a frontend component and an event
|
||||
handler to function properly, while the frontend component responsible for
|
||||
drawing out and managing other components implement no
|
||||
event handler.
|
||||
drawing out and managing other components implements no
|
||||
event handler, so it only exists on the frontend.
|
||||
|
||||
In the Tutorial Framework most of the built-ins define APIs, which are TFW messages
|
||||
that can be used to interact with them.
|
||||
@ -205,26 +205,31 @@ certain command are executed by the user.
|
||||
\pic{figures/terminal.png}{The Frontend Terminal of TFW Running top}
|
||||
|
||||
The implementation of reading command history is quite an exotic one.
|
||||
The framework need to be able to detect if the user has executed any command in the
|
||||
container.
|
||||
This is not an easy thing to accomplish without relying some sort of heavyweight
|
||||
The framework needs to be able to detect if the user has executed any command in the
|
||||
container using an interactive bash session.
|
||||
This is not an easy thing to accomplish without relying on some sort of heavyweight
|
||||
monitoring solution such as Sysdig%
|
||||
\footnote{\href{https://sysdig.comq}{https://sysdig.com}}.
|
||||
I deemed most simiar systems a huge overkill to implement this functionality, and their
|
||||
memory footprints are not something we can really afford here.
|
||||
Another way would be to use \texttt{pam_tty_audit.so} in the PAM%
|
||||
memory footprints are not something we could afford here.
|
||||
Another way would be to use \texttt{pam\_tty\_audit.so} in the PAM%
|
||||
\footnote{Linux Pluggable Authentication Modules:
|
||||
\href{http://man7.org/linux/man-pages/man3/pam.3.html}
|
||||
{http://man7.org/linux/man-pages/man3/pam.3.html}}
|
||||
configurations responsible for logins, as this allows various TTY auditing, but
|
||||
I have found an ever simpler approach to the problem in the end.
|
||||
configurations responsible for logins, as this allows for various TTY auditing functions,
|
||||
but I have found an ever simpler approach to the problem in the end.
|
||||
By using the inotify system built into TFW, I can set up the user's environment in
|
||||
such a way, that I can enforce or determine the location of the bash \texttt{HISTFILE}%
|
||||
such a way, that I can enforce and determine the location of the bash \texttt{HISTFILE}%
|
||||
\footnote{This environment variable contains the path to the file bash writes command
|
||||
history to}
|
||||
of the user.
|
||||
This way I can monitor changes made to this file and read the commands executed
|
||||
by the user from it.
|
||||
It is important to keep in mind that the user is able to ``sabotage'' this method%
|
||||
\footnote{By unsetting the \texttt{HISTFILE} envvar for example},
|
||||
but that should not be an issue as this is not a feature that is intended to be
|
||||
used in competitive environments (and if the users of a tutorial intentionally
|
||||
break the system under themselves, well, good for them).
|
||||
|
||||
\section{Console Component}
|
||||
|
||||
@ -240,7 +245,7 @@ experience similar to working in an IDE on your laptop.
|
||||
|
||||
\pic{figures/console_and_editor.png}{The Console Displaying Live Process Logs Next to the TFW Code Editor}
|
||||
|
||||
\section{Process Management}
|
||||
\section{Process Management}\label{processmanagement}
|
||||
|
||||
The framework includes an event handler capable of managing processes running inside
|
||||
the \texttt{solvable} Docker container.
|
||||
@ -302,11 +307,82 @@ digitally signed messages only.
|
||||
In the event of a successful FSM step, this component is going to broadcast
|
||||
a message showcased as an example in the beginning of Chapter~\ref{atouroftfw}.
|
||||
|
||||
\section{Additional Frontend Features}
|
||||
\section{Web Component}
|
||||
|
||||
The frontend of the framework exposes some additional APIs through
|
||||
TFW messages.
|
||||
The web component allows developers to configure what web application should
|
||||
be displayed on the frontend.
|
||||
There are two options for doing this:
|
||||
\begin{enumerate}
|
||||
\item Supply the URL of a web application served from the
|
||||
Docker container to be displayed
|
||||
\item Implement an Angular component on the frontend and display it
|
||||
\end{enumerate}
|
||||
|
||||
In most cases, when developers make tutorials on Python and Java topics for
|
||||
example, they will implement a web application in the respective programming
|
||||
language the exercise is about and most developers have no experience in
|
||||
Angular development.
|
||||
This is why more often then not the fist option is chosen.
|
||||
This feature is implemented by embedding a standard HTML iframe%
|
||||
\footnote{\href{https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe}
|
||||
{https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe}}
|
||||
inside the frontend, which is controllable by TFW
|
||||
(as an example it can be reloaded or navigated from the framework).
|
||||
|
||||
Watchful readers might now be thinking about how does ``controlled by the framework''
|
||||
thing work with the Same Origin Policy%
|
||||
\footnote{\href{https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy}
|
||||
{https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin\_policy}}
|
||||
being in effect?
|
||||
The answer is that developers must use a \emph{relative url}, that is an URL relative
|
||||
to the entry pont of the TFW frontend itself.
|
||||
To allow serving several web applications from a single port the framework
|
||||
supports optional reverse-proxy configurations through the nginx%
|
||||
\footnote{\href{http://nginx.org}{http://nginx.org}} web server ran by the framework.
|
||||
More on this in a later chapter.
|
||||
|
||||
\section{Various Frontend Features}
|
||||
|
||||
The angular frontend of features several different layouts.
|
||||
These layouts are useful to accomodate different workflows for users,
|
||||
such as the previous exampe of editig code and being able to view the
|
||||
result of said code in real time next to the editor.
|
||||
Another example would be editing Ansible playbooks in the file editor,
|
||||
and then trying to run them in the terminal.
|
||||
There are also almost full screen views for each component that makes sense
|
||||
to be used that way.
|
||||
|
||||
The frontend was designed in a way to be fully responsive in windows sizes
|
||||
that still keep the whole thing usable (i.e.\ it would not be practial to start
|
||||
solving TFW tutorials on a smart phone, simply because of size limits, so they are
|
||||
not supported, but the frontend still behaves as expected on small laptops or bigger tablets).
|
||||
This is not an easy thing to impelent and maintain due to the lots of small
|
||||
incompatibilites between browsers given the complexity of the frontend.
|
||||
|
||||
Just remember that a few years ago the clearfix%
|
||||
\footnote{\href{https://stackoverflow.com/questions/8554043/what-is-a-clearfix}
|
||||
{https://stackoverflow.com/questions/8554043/what-is-a-clearfix}}
|
||||
hack was the industry standard in creating CSS layouts.
|
||||
The situation has improved \emph{a lot} since then with flexboxes
|
||||
and grid layouts despite the sheer chaos that is generally involved in web
|
||||
standardization efforts, but CSS espacially%
|
||||
\footnote{\href{https://developer.mozilla.org/en-US/docs/Web/CSS/CSS3}
|
||||
{https://developer.mozilla.org/en-US/docs/Web/CSS/CSS3}}.
|
||||
|
||||
The framework frontend is built on grid layout and flexboxes%
|
||||
\footnote{\href{https://developer.mozilla.org/en-US/docs/Web/CSS/CSS\_Grid\_Layout}
|
||||
{https://developer.mozilla.org/en-US/docs/Web/CSS/CSS\_Grid\_Layout}},
|
||||
which gives us the best hopes of being able to maintain it down the line.
|
||||
It would involve unimaginable horrors to support this multi-layout
|
||||
frontend on older browsers, so browsers without flex and grid
|
||||
support are not supported by TFW.
|
||||
Arguably this is a good thing, as people should keep their browsers up to date to
|
||||
follow frequent security patches anyway, so let this serve as a reminder to
|
||||
developers looking to get into IT security that the first step is to
|
||||
keep your software up to date.
|
||||
|
||||
The frontend of the framework exposes some additional APIs.
|
||||
These include the changing of layouts, selecting the terminal or console
|
||||
component to be displayed, the possibility of dynamically modifying other
|
||||
frontend configuration (such as the frequency of autosaving the files in the editor)
|
||||
component to be displayed, the possibility of dynamically modifying
|
||||
frontend configuration values (such as the frequency of autosaving the files in the editor)
|
||||
and more.
|
||||
|
Reference in New Issue
Block a user