nwrenger / schiller-db

A repo with the backend and frontend of the Schillernova's Database Managment Software.

Schillernover's Database Management or for short SchillerDB / schiller-db

A repo with the server-side backend and the frontend of the Database Application of the Schillerschool for the upcoming project week.

Download

The latest builds can be downloaded from the releases page.

Usage

Just run the binary/executable file provided in the release. Make sure it's in the same Directory as the dummy data files (benutzer.txt, logins.txt) and admin.env file otherwise it won't start. The Server Address and Port is defaulted to 0.0.0.0:80, you can change them with the flags -p (port) and -a (address). Run it with enough permissions (when using it with the default config, you have to run it as admin/sudo). In addition, using the admin.env file you can define your admin, which can't be deleted. This admin can add other Users and their permissions. Without those permissions you are unauthorized and can't interact with the Server/Database.

Architecture

This application follows the 3-tier principle.

• UI Layer: Getting the Data from Server Calls.
• Application/Server Layer: This is implemented using Rust and Rocket. Including a Swagger UI integration.
• Database Layer: The SQLite database that stores the persistent data specific to a project.

UI Layer

Developed by me and a few others (look to contributions). You can see a current state of the development by running it, look therefore into Downloads.

It's developed by using intern Server Calls, Svelte and Bootstrap (for the UI). I finally finished the refactoring of the old plain JS version to this new and improved Svelte version. It's now way better structured and easier to develop new stuff. And Svelte generally is a big upgrade compared to old plain JS, it's a really good WebDev Framework.

A Picture of the Main Page:

Application/Server Layer

This layer is implemented in Rust (src) and Rocket (0.5 rc-3).

It is responsible for the consistency checks and business logic. This layer also manages the database connection to store and fetch the project data.

Besides that, it also consists the management and logic for a server using Rocket, including Swagger UI (using the Utoipa Crate).

Server

The Server calls are:

• 8 for data table criminal and workless
• 6 for data table user
• 5 for logins (create, fetch, edit, delete, delete_all)
• stats - getting general statistics/infos

Swagger UI integrated via Utoipa:

Schemas:

Security:

• User System, an Admin, defined thought the admin.env file
• Admin can add User with Permissions what they can do and cannot do like: Reading/Writing for each Data Type (User, Workless, Criminal)
• each user can change their passwords
• the passwords are internally hashed and cannot be directly red out of the database
• logging every Server call (excluding Swagger UI - general GET requests) to separate file called 'log.txt' with Information who did what

Database Layer

The SQLite database has the following schema:

(The bold printed texts are the primary keys!)

Current Todo's

• DB Management
• Making a real/openable DB File
• Fetching User Data from IServ
• Server Integration
• Swagger UI Integration
• Testing, Fixing, etc.
• Logging? Why not!
• SideBar -> User
• Searching (including workless, criminal, user)
• Main Input Container -> Stats when nothing and User when one is selected -> include changing and adding them
• Login -> at the current Logout Button make a profile menu
• In profile menu: Logins Creator with permission selection (makes our job a lot easier)
• Workless Management
• Criminal Management
• fix Add Button (currently a little bit buggy)
• Better Criminal/Workless adding process
• Integration for Mobile
• Finished Criminals Extended Data Fields
• More specific search
• Network test (after we are finished with the UI)
• Using it in the project week -> worked really well
• Changes due to customer feedback -> absence into workless
• Moving Frontend to Svelte

schiller-db's Issues

Don’t put keys into your source code

https://github.com/nwrenger/sndm/blob/927732e4d9eb5e020109e51476f5939467c386de/src/server.rs#LL46C30-L46C30

Just use const variables with env!:

const KEY_A: &str = env!("SNDM_KEY_A");

Simplify Error Reporting

https://github.com/nwrenger/sndm/blob/927732e4d9eb5e020109e51476f5939467c386de/src/server.rs#L47

The unauthorized error could be simpler, just having no string field. Then this whole distinction between having no key and having a wrong one could be left out and just „Unauthorized“.