Skip to content

Development

Jump to bottom
Arthur Meyniel edited this page Jan 26, 2024 · 23 revisions

Introduction

Welcome to the dev part of the project, here you will find all the informations that will help you understand how the code works and how to develop new features.

Getting started

Requirements

  • Node.js
  • Java 11
  • Maven 2.7
  • MySQL or MariaDB
  • RabbitMQ

Installation

To be able to develop WebCube, you will need to:

  1. Clone the repository : git clone https://github.com/IDE-PFE-S9/WebCube.git
  2. go inside the web-app directory and install the librairies: cd web-app & npm install
  3. Start the front-end application: npm run dev (runs on localhost:5173)
  4. Go to the api directory: cd ../api
  5. Start a MySQL/MariaDB database and set the url and credentials of it inside the api/src/main/resources/application-dev.properties file
  6. Comment out the Proxy setting in the UserController.java (line 96/98)
// Set the proxy
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("192.168.4.8", 3128));
clientHttpReq.setProxy(proxy);
  1. Start the back-end application: mvn spring-boot:run (runs on localhost:4444)
  2. Start your RabbitMQ server (see RabbitMQ documentation https://www.rabbitmq.com/#getstarted)
  3. Run a Java Worker from here: https://github.com/theolurat/java-workers-docker

How it works?

WebCube is a web-based IDE focused on Java development. It aims to allow ESEO students to learn Java without having to install it. The Java code is compiled and jar-ified on server, using RabbitMQ to dispatch the jobs to dedicated workers. The jar files are then sent to the web application, where there are run using CheerpJ, a JVM developed in WASM.

compilation_process

Security

The application accesses are restrained using Spring Security. To authentifiate, the user is redirected on an Azure connection page, linked to the ESEO Azure Active Directory. Once the user is authentified using Azure, this token is used by the API to create a proprietary Json Web Token, that contains more informations than the Azure Token. This JWT has a life-span of exactly one day and will be used to authentifiate the user at each API call.

Authentication

UML generation

To generate UML from the Java code, we use ANTLR4, a powerful parsing tool which comes out of the box with a Javascript lexer and a parser for Java. This allow us to handle the whole process on the client side, thus avoiding API calls. The diagrams are made with Mermaid.js, which is a library that provides a descriptive language to create multiple sorts of diagrams. The passage from ANTLR4 to Mermaid is handled directly by us inside the svelte files, retriving for each Java file the classes, methods, fields, interfaces and modificators.

Archive cyphering

When downloading the archive, a symmetric key is generated based on the username and used to cypher the archive. Once the archive cyphered, the key is cyphered using the public key of the teachers, and added to the archive.

When opening the archive, the application fetches the role of the user. If it's a teacher, the key is deciphered and used to decipher the archive, allowing the teachers to open any archive. If it's a student, the symmetric key is generated based on he's username and used to decipher the archive. If the archive was created by the same user, he will have access to all the code, otherwise the deciphering will not work since the key used will be wrong.

This design ensures data privacy and access control, allowing teachers to oversee all archives while restricting students to view only those they have created, maintaining a secure and organized educational environment.

archive_cyphering

TP structure

The TPs are handled with the ESEO GitLab. In the database, for each TP there is a git url, allowing the server to clone the repository of the TP.

Once the TP is opened on the client, the user can modify it. When saving, a new branch is created on the git, with the uuid of the student as name.

A TP must have a specific structure to be well handled by the client

<TP-name>
├── <notice-name>.md
├── descriptor.xml
├── lib
└── src
    ├── main
        └── packages
             ├── Main.java
             └── MainTest.java
    └── test

Inside the lib folder, just put the .jar files needed. Multiple notices can be in the structure, they will be opened inside a markdown viewer inside WebCube.

Untitled-2023-12-02-2300

Testing

The tests are handled in the same way as the executable code. The Java code is compiled and jar-ified on server, using RabbitMQ to dispatch the jobs to dedicated workers. The jar files are then sent to the web application, where there are run using CheerpJ, a JVM developed in WASM. The only twist is that the manifest of the jar file is specifying another main class, which discovers and runs the tests.

Code Structure Overview

There are two main folders in the project :

  • api
  • web-app

API

Written in Java 11, it uses Maven + Spring Boot 2.7. It's the RESTful API

You will also need to have a MySQL/MariaDB server running. You can change the url/username/password for development inside api/src/main/resources/application-dev.properties

Capture d’écran 2024-01-24 à 11 11 22

To run it for development purposes:

cd api
mvn spring-boot:run

It is developed using a layered architecture, including 4 layers of abstraction:

  • controller
  • services
  • model
  • repository

this allows a clear division of the tasks, leading to better maintainability.

Untitled-2023-12-02-2300

Web-app

Mainly written using the Svelte framework, this represents the client-side application.

To run it for development purposes:

cd web-app
npm install
npm run dev

--> Runs at http://localhost:5173

Since this is a single page web application, there is no routing. Everything is directly inside the layout.svelte file. The layout contains all the components calls to display the full application. The components are located inside the lib folder. The application heavily relies on Svelte stores, which are declared inside the stores.js file.

Server-side code compilation

This part is fully handled inside another git repository here: https://github.com/IDE-PFE-S9/workers-java

Testing

This project is tested using Playwright. You can run the tests by calling npm run test. There are no unit tests, because the functionalities are too complex (involving multiple containers and file compression processes). So we choose to focus on end-to-end tests. All the tests are located insinde the web-app/tests folder. I strongly advice to establish a full test server deployment before going any further with testing.

ESEO WebCube
Copyright © 2018 | Written by Arthur MEYNIEL

Clone this wiki locally