* format: add line breaks

## System Overview

The INJECT Exercise Platform (IXP) is architecturally structured into two distinct components: the frontend and the backend.

This separation allows for clear delineation of roles and responsibilities, enhancing modularity and scalability within the system.

The INJECT Exercise Platform (IXP) is architecturally structured into two distinct components:

the frontend and the backend.

This separation allows for clear delineation of roles and responsibilities,

enhancing modularity and scalability within the system.

The architecture of the IXP can be visualized as follows:

This diagram illustrates the high-level architecture of the IXP.

It is composed out of these parts:

* Frontend: The frontend component serves as the user interface of the IXP, allowing users to interact with the system.

* Frontend: The frontend component serves as the user interface of the IXP,

  allowing users to interact with the system.

  It includes four main parts:

    * Trainee View: This view is designed for trainees participating in tabletop exercises.

      It provides functionalities tailored to their role, such as accessing exercise scenarios, submitting responses, and general interaction with the exercise.

      It provides functionalities tailored to their role, such as accessing exercise scenarios,

      submitting responses, and general interaction with the exercise.

    * Instructor View: This view is tailored for instructors or facilitators overseeing tabletop exercises.

      It offers capabilities for monitoring trainee progress, and providing guidance during the exercise.

    * Analytics: The analytics view provides insights and analytics related to the tabletop exercises conducted on the platform.

      It includes metrics such as participation rates, completion times, and performance trends.

    * Exercise Panel: The exercise panel enables users to view and manage exercises available on the platform, including creating new exercises, editing existing ones, and organizing exercise-related resources.

    * Exercise Panel: The exercise panel enables users to view and manage exercises available on the platform,

      including creating new exercises, editing existing ones, and organizing exercise-related resources.

* Backend: The backend component serves as the backbone of the INJECT platform, handling data management, authentication, and communication with the frontend.

* Backend: The backend component serves as the backbone of the INJECT platform, handling data management,

  authentication, and communication with the frontend.

  It includes several parts:

    * Exercises: This module manages the creation, modification, and storage of tabletop exercises on the platform.

    * Exercises: This module manages the creation, modification,

      and storage of tabletop exercises on the platform.

    * Exercise Definitions: The exercise definitions module stores templates and definitions for different types of exercises.

      These definitions include details such as injects, emails and tools.

      It also checks and ensures that definitions are correctly configured and set up.

      For a more in-depth explanation of definitions, please refer to [definitions documentation](definitions/README.md).

    * Running Exercise: This module manages the execution and runtime aspects of tabletop exercises, including tracking the progress of ongoing exercises and managing the flow of injects.

    * Running Exercise: This module manages the execution and runtime aspects of tabletop exercises,

      including tracking the progress of ongoing exercises and managing the flow of injects.

    * Authentication: Handles user authentication and authorization, ensuring secure access to the platform's functionalities.

## Used Technology

Key components of the backend architecture include:

* Python Backend: The backend of the IXP is implemented using Python.

* Django Framework: Django, the most popular web development framework for Python, is used to build the backend application.

* Django Framework: Django, the most popular web development framework for Python,

  is used to build the backend application.

  Django provides robust features for database management, user authentication, and more.

* GraphQL API: The backend exposes a GraphQL API for communication with the frontend.

  GraphQL allows efficient data fetching and enables the client to request only the data it needs.

* Django REST Framework: For file transfers and other functionalities not supported by GraphQL, a REST API is implemented using Django REST Framework.

* Django REST Framework: For file transfers and other functionalities not supported by GraphQL,

  a REST API is implemented using Django REST Framework.

### Frontend Technology

* React Frontend: The frontend application of the IXP is developed using React, library for building user interfaces.

* TypeScript: TypeScript is used instead of JavaScript to ensure type safety and improve code quality.

* React Hooks: React hooks play a crucial role in modern React programming, providing essential features such as state management and performing side effects.

* Libraries and Tools: Various libraries and tools, including Yarn, Vite, Apollo Client, and Generouted, are utilized for package management, building, data management, and routing within the frontend application.

* React Hooks: React hooks play a crucial role in modern React programming,

  providing essential features such as state management and performing side effects.

* Libraries and Tools: Various libraries and tools, including Yarn, Vite, Apollo Client, and Generouted,

  are utilized for package management, building, data management, and routing within the frontend application.

## Security overview

1. Client → Server: Get the backend version from the REST API.

  (No cookies are set yet.)

2. Client ← Server: Responds with backend version and `SET_COOKIE`

  with new `sessionid` and CSRF cookie.

  with `CSRF cookie` needed for POST actions.

In this state, the server established a session with the client.

The client did not authenticate yet, and thus the session attribute _user_ is set to _AnonymousUser_.

All further requests from the client should now contain the _sessionid_ and _csrf_ cookie together with the _X-csrftoken_ header of requests (most importantly for safe login!).

The client can now make any request to endpoints, which do not enforce authenticated requests.

On every request, the match of _csrf_ cookie and _X-csrftoken_ header is checked.

The next important step in our schema is **login**:

At this stage, the client has obtained the _CSRF cookie_.

Since the client is not yet authenticated, any requests made will include `AnonymousUser`as the requester's identity,

indicating an unauthenticated state.

All subsequent POST requests from the client must include both the _csrf cookie_ and the _X-csrftoken header_.

The client can now make requests to endpoints that do not require authentication.

For every request, the server checks for a match between the _csrf cookie_ and the _X-csrftoken header_

to prevent cross-site request forgery.

POST requests that do not contain matching _csrf cookie_ and _X-csrftoken header_ will fail

with response `403 Forbidden`.

The next crucial step in the process is **login**:

``` mermaid

sequenceDiagram

  Server->>Client: Server generates new session

```

3. Client → Server: Sends a login request on the GraphQL login endpoint

  containing the username and password (and most importantly,

  the _sesisonid_ and _csrf_ cookie with _X-csrftoken_ header set to the

  value of the _csrf_ cookie to prevent cross-site request forgery).

4. Client ← Server: If the provided credentials were correct,

  the server generated a new session with attribute _user_ set

  to User model of user who successfully authenticated themselves and

  responded with `SET_COOKIE` containing the new _sessionid_ cookie

  and the new _csrf_ cookie.

3. Client → Server: Sends a login request on the GraphQL endpoint (login mutation) containing the username and password.

4. Client ← Server: If the provided credentials are valid, the server generates a _new session_,

setting the _user_ attribute of the session to the corresponding user that has successfully authenticated.

The server then responds with a `SET_COOKIE` header, containing both the new `sessionid` cookie and a new `csrf` cookie.

The client is expected to drop the old _sessionid_ and _csrf_ cookie and replace them with the new ones.

Also, every request from now on should contain _X-csrftoken_ value of the new _csrf_ cookie.

The client is expected to drop the old _csrf cookie_ and replace them with the new one.

Also, every request from now on should contain _X-csrftoken_ value of the _**new** csrf cookie_.

For further information, refer to the official documentation on:

### Basic authentication

For the purposes of more convenient development, basic authentication is also supported

according to the [RFC 2617](https://datatracker.ietf.org/doc/html/rfc2617#section-2) standard.

for the REST API according to the [RFC 2617](https://datatracker.ietf.org/doc/html/rfc2617#section-2) standard.

<!--

### Authorization