Skip to content

Commit 2acb06f

Browse files
Marrrco7Marrrco7
authored
Merge pull request #8 from Marrrco7/main
Merge changes from release into develop
2 parents bbb5b2f + a7eac86 commit 2acb06f

File tree

1 file changed

+209
-0
lines changed

1 file changed

+209
-0
lines changed

‎README.md

Lines changed: 209 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,209 @@
1+
2+
3+
Overview
4+
--------
5+
6+
Dynamic web application developed using Django, allowing for easy addition, update, display, and deletion of game information. The application integrates with a PostgreSQL database to efficiently store and retrieve game data for a videogames company (Threading Labs).
7+
8+
Table of Contents
9+
-----------------
10+
- [Project Structure](#project-structure)
11+
- [Features](#features)
12+
- [Functionalities](#functionalities)
13+
- [Analysis and Design](#analysis-and-design)
14+
- [System Architecture](#system-architecture)
15+
- [Security](#security)
16+
- [Testing](#testing)
17+
- [Setup and Deployment](#setup-and-deployment-steps)
18+
19+
## Project Structure
20+
-----------------
21+
22+
23+
## Features
24+
--------
25+
26+
- **CRUD operations**: Create, Read, Update, and Delete video game entries.
27+
- **User Authentication**: Secure login and logout functionalities for staff members.
28+
- **Permissions**: Restrict access to certain views only to users with certain permissions.
29+
- **Responsive Design**: Easy to use UI.
30+
31+
### Functionalities
32+
33+
- **Game Adding**: Users can add new video games by filling the form rendered by the views.py
34+
- **Details Editing**: Users can update the existing game information.
35+
- **Game Deletion**: Possibility to easily remove games from the catalog (with permission required).
36+
- **View Game List**: Users can view a list of all games in the catalog.
37+
- **User Authentication**: Users must log in to access the application.
38+
- **Permissions**: Only authorized users can add, edit, or delete games (Admins and managers).
39+
- **Security**: Implemented proper authentication and authorization mechanisms (CSRF tokens, loggin authentication).
40+
- **Usability**: UI intuitive and easy to navigate, designed for staff memebers with non technical backround.
41+
42+
43+
## Analysis and Design
44+
-------------------
45+
46+
### System Architecture
47+
48+
![image](https://github.com/user-attachments/assets/9d3de266-75fe-41f7-a89f-6c847b73d8c6)
49+
50+
51+
The architecture is composed by these following:
52+
53+
- **Web Application**: The project is build as a Django webApp that serves as a backend. It handles data validation, business logic
54+
and HTTP requests by the users thanks to the Django MVT architecturarl pattern:
55+
56+
- **Models**: Define the structure of the database (VideoGame and Genre models).
57+
- **Views**: Handle the business logic and provides posibility to interact with the models.
58+
- **Templates**: Render the user interface using HTML and Bootstrap4 for a cooler look.
59+
60+
- **Database**: The project uses a relational postgre SQL database for data storage and efficient retrieving of information. The Django App interacts with this database
61+
via the ORM (Object Relational Mapping), making it easier to perform CRUD operations. The columns of the database are defined in the Django models.py: Title, Release date, Description,
62+
and Genre. The database design is composed by two tables: Videogame and Genre, implemented with a one to many relationship (a genre can have multiple games, but each genre's game must be only one).
63+
64+
**Tables**:
65+
66+
1. **Genre**
67+
- `id`: Primary key (automatically generated by Django)
68+
- `title`: String (50 chars)
69+
70+
2. **VideoGame**
71+
- `id`: Primary key
72+
- `title`: String (100 chars)
73+
- `release_date`: Date
74+
- `description`: String (100 chars)
75+
- `genre_id`: Foreign key pointing to the `Genre` table
76+
77+
78+
- **Local Environment**: The application is running in a local server allowing staff members to access the WebApp by connecting to the IP address of the local machine.
79+
80+
## Security
81+
82+
The Django WebApp project includes several security measures to ensure reliabilty and safey for user control:
83+
84+
- **User Authentication**: Only authenticated users can access the application. Django’s built in authentication system is used to handle login and session management securely.
85+
86+
- **Role Based Permissions**: Access to specific functionalities is restricted based on user permissions. Users with certain roles (for example Admin, Manager) have superior access to specific areas, ensuring that only authorized users can for instance delete data.
87+
88+
- **CSRF Protection**: Django’s CSRF "Cross-Site Request Forgery" protection is enabled to prevent unauthorized actions that can come from malicious sources. All forms include CSRF tokens, adding an additional layer of security for the submitted data from the users.
89+
90+
- **Password Hashing by Django**: Django securely hashes user passwords using a strong hashing algorithm, which is PBKDF2 by default, before storing them in the database. This ensures that even if the database is compromised, passwords are not stored as plain text.
91+
92+
- **Environment Variables for Sensitive Data**: Sensitive information, such as database credentials, are stored in environment variables, a (`credentials.env` file) and not hardcoded in the source code to prevent exposure of our credentials.
93+
94+
All this securuty measures were applied following best practices and ensure user validation, access, and a robust functionality of the web application.
95+
96+
## Testing
97+
98+
The project incorporates a test suite in tests.py to ensure stability and correctness of core functionalities in models, forms, and views:
99+
100+
- **Model Tests**: Verify that models like `Genre` and `VideoGame` can be created, stored, and retrieved accurately. These tests ensure that data attributes such as titles, release dates, and associations between models are properly handled.
101+
102+
- **Form Tests**: Validate that forms accept valid data and reject invalid submissions. For example, the `VideogameForm` is tested to confirm it only allows submissions that meet specified field requirements.
103+
104+
- **View Tests**: Ensure that views load the correct templates, return expected HTTP status codes, and display the right content. Views are tested for their response to user actions, with checks for the proper template usage and access control.
105+
106+
107+
## Setup and Deployment Steps
108+
109+
This section shows the steps to set up, test, and deploy the application into a local server, that in the live demo was my machine.
110+
111+
### 1. Database Migrations
112+
- After creating or making changes to the Django models, it is necessary make and apply migrations to update the database schema accordingly.
113+
- Run the following commands to make and apply migrations:
114+
```bash
115+
python manage.py makemigrations
116+
python manage.py migrate
117+
```
118+
-This will ensure us of having the latest database model in our database.
119+
120+
### 2. Running Tests
121+
- To guarantee that the application works as expected, run tests defined in `tests.py`. The tests are written to ensure correct setup, catalog visualisation, form submission, videogame creation.
122+
- To run all the tests, run the command:
123+
```
124+
python manage.py test
125+
```
126+
- Check the output to see if all the tests passed.
127+
128+
### 3. Using Waitress for Deployment
129+
- For production deployment, we are using Waitress, a WSGI server that is recommended for Windows.
130+
- First, install Waitress if you haven’t already, just run:
131+
```
132+
pip install waitress
133+
```
134+
135+
### 4. Running the Server with Waitress
136+
- Then, create a new file `run_waitress_server.py` to be able to run the server. Here is an example of how the code might look, just adjust the host and port accordingly:
137+
138+
```
139+
# run_waitress_server.py
140+
from waitress import serve
141+
from my_project.wsgi import application
142+
143+
if __name__ == "__main__":
144+
serve(application, host="0.0.0.0", port=8000)
145+
```
146+
- Run `run_waitress_server.py` using:
147+
```
148+
python run_waitress_server.py
149+
```
150+
- This will start the application on `http://0.0.0.0:8000`, or the specific IP address of your local machine, making it accessible on the local network.
151+
152+
### 5. Testing the Deployment
153+
- Access the WebApp at `http://serverIP:8000` from other devices on the network to verify functionality and stability.
154+
155+
### 6. Setting the environmental variables for the database credentials
156+
157+
In order to hash the sensitive data for connecting to our database, environmental variables where used wiht the `django environ` package:
158+
159+
To install just run:
160+
161+
```
162+
pip install django-environ
163+
```
164+
165+
After that, create an env. file with the credentials to connect to the database, somehting like this:
166+
167+
```
168+
DB_NAME=your_database_name
169+
DB_USER=your_database_user
170+
DB_PASSWORD=your_database_password
171+
DB_HOST=your_database_host
172+
DB_PORT=your_database_port
173+
```
174+
175+
176+
then update the settings.py to use the environmental variables, it might look like:
177+
```
178+
DATABASES = {
179+
'default': {
180+
'ENGINE': 'django.db.backends.postgresql',
181+
'NAME': env('DB_NAME'),
182+
'USER': env('DB_USER'),
183+
'PASSWORD': env('DB_PASSWORD'),
184+
'HOST': env('DB_HOST', default='localhost'),
185+
'
186+
}
187+
}
188+
```
189+
190+
Note: the credentials.env file was added to the gititgnore in this repository for obvious reasons, so the credentials are not visible for everyone.
191+
192+
-After following this proccess we would have enabled a better way of securing our sensitve data without havind hardcoded the credentials.
193+
194+
195+
196+
### User Interface Design
197+
- **Base Template**: Includes navigation and common UI elements.
198+
- **Videogame List**: Displays a table of all video games with options to edit or delete.
199+
- **Videogame Form**: Form for adding or editing a video game.
200+
- **Authentication Pages**: Login and logout pages.
201+
202+
**Design Elements**:
203+
204+
- **Bootstrap 4.3.1**: Used for responsive design and styling (includes the jumbotron component).
205+
- **Font Awesome 6.6.0**: Provides icons for buttons and actions.
206+
- **Jumbotron Component**: Used for the header section in the base template.
207+
- **Base Template**: Includes navigation and most common UI elements.
208+
- **Videogame List**: Extends Base.html, displays a table of all video games with options to edit or delete.
209+
- **Videogame Form**: Extends Base.html, form for adding, deleting or updating videogames

0 commit comments

Comments
 (0)