From ae5c842f2b9722cdf9621ab9ce5971cd1a2e650e Mon Sep 17 00:00:00 2001 From: Actions Date: Sat, 23 Nov 2024 17:26:06 +0000 Subject: [PATCH] Deployed 3408c15 to 1.0 with MkDocs 1.6.1 and mike 2.1.3 --- 1.0/installation/manual/index.html | 154 +++++++++++++++-------------- 1.0/search/search_index.json | 2 +- 2 files changed, 79 insertions(+), 77 deletions(-) diff --git a/1.0/installation/manual/index.html b/1.0/installation/manual/index.html index 43a2b47..1518303 100644 --- a/1.0/installation/manual/index.html +++ b/1.0/installation/manual/index.html @@ -1906,8 +1906,7 @@

APTRS Django APIs Setup

Bash
sudo adduser aptrs
 sudo usermod -aG sudo aptrs
 usermod -a -G www-data aptrs
-sudo chown -R aptrs:www-data /home/aptrs
-sudo su - aptrs
+sudo su - aptrs

APTRS uses Python Poetry to manage dependencies, so we ensure its installation.

Bash
curl -sSL https://install.python-poetry.org | python3 -
@@ -1921,7 +1920,7 @@ 
APTRS Django APIs Setup

 cd APTRS
 poetry install
 cd APTRS
-cp cd APTRS .env  # The .env file should be located in the same directory as the manage.py file.
+cp env.example .env  # The .env file should be located in the same directory as the manage.py file.
After obtaining the .env file from the demo environment file, ensure that you update it with the following details: the password for Redis, the PostgreSQL hostname or IP address, the Redis hostname or IP address, the secret key, and any other necessary information. It's important to review all the details in the .env file carefully. For more information on configuring the .env file and the various data it contains, please refer to the Environment Variables section.

Few Important details for .env file:

@@ -2036,92 +2035,95 @@

Nginx Setup

We have everything set up, and our APIs are running with Gunicorn. Now, we need to configure the frontend to serve static files with Nginx and connect Gunicorn to Nginx. To get started, we first need to install Nginx using the command below:

Bash
sudo apt install nginx
+

Since our frontend and backend are in the user directory, we will encounter a permission error from Nginx. To resolve this, we will grant access to the www-data user group with the command below:

+
Bash
sudo chown -R aptrs:www-data /home/aptrs
+

To complete the setup, we can assume the domain name for our web server is demo.aptrs.com. The configuration below will have the nginx configuration files or folder names based on the domain, which users should replace with their actual domain.

Next, we will create a new server block in the Nginx sites-available directory using the following command:

-
Bash
sudo nano /etc/nginx/sites-available/demo.aptrs.com
+
Bash
sudo nano /etc/nginx/sites-available/demo.aptrs.com
 

 
Paste the Below nginx configuration,

-
Bash
# HTTP server configuration
-server {
-    listen 80;
-    server_name demo.aptrs.com;  # Replace with your domain
-
-    server_tokens off;
-    client_max_body_size 100M;
-
-
-
-    ### Host Validation - > Update according to your need
-    if ( $host !~* ^(demo.aptrs.com)$ ) {
-        return 444;
- }
-
-    # Pass all /api/* to the Django backend 
-    location /api/ {
-        proxy_pass http://unix:/run/gunicorn.sock;
-        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-        proxy_set_header X-Forwarded-Proto $scheme;
-        proxy_set_header Host $host;
-        proxy_redirect off;
- }
-
-    # Home page for frontend
-    location / {
-    root /home/aptrs/APTRS/frontend/dist;
-    index index.html index.htm;
-    try_files $uri $uri/ /index.html =404;
- }
-    ## Server Static from Django over nginx
-    location /static/ {
-        alias /home/aptrs/APTRS/APTRS/static/; 
- }
-
-    # Blocked, accessing the whole media folder may lead to access to sensitive images like POC images, 
-    #location /media/ {
-    #    alias /home/aptrs/APTRS/APTRS/media/;  # Path to your media files
-    #} 
-
-    location = /favicon.ico { 
-    alias /home/aptrs/APTRS/frontend/dist/favicon.ico;
-    access_log off; 
-    log_not_found off; 
-    
- }
-
-    ## Server user profile photo
-    location /media/profile/ {
-        alias /home/aptrs/APTRS/APTRS/media/profile/;  # Path to your media files
- } 
-
-    ## Server Company Logo Images
-    location /media/company/ {
-        alias /home/aptrs/APTRS/APTRS/media/company/;  # Path to your media files
- }
-
-    ## HTML Report design Images like background images
-    location /media/report/ {
-        alias /home/aptrs/APTRS/APTRS/media/report/;  # Path to your media files
- } 
-
-    access_log /var/log/nginx/APTRS_access.log;  # Path to access log file
-    error_log /var/log/nginx/APTRS_error.log;   # Path to the error log file
-}
+
Bash
# HTTP server configuration
+server {
+    listen 80;
+    server_name demo.aptrs.com;  # Replace with your domain
+
+    server_tokens off;
+    client_max_body_size 100M;
+
+
+
+    ### Host Validation - > Update according to your need
+    if ( $host !~* ^(demo.aptrs.com)$ ) {
+        return 444;
+ }
+
+    # Pass all /api/* to the Django backend 
+    location /api/ {
+        proxy_pass http://unix:/run/gunicorn.sock;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header Host $host;
+        proxy_redirect off;
+ }
+
+    # Home page for frontend
+    location / {
+    root /home/aptrs/APTRS/frontend/dist;
+    index index.html index.htm;
+    try_files $uri $uri/ /index.html =404;
+ }
+    ## Server Static from Django over nginx
+    location /static/ {
+        alias /home/aptrs/APTRS/APTRS/static/; 
+ }
+
+    # Blocked, accessing the whole media folder may lead to access to sensitive images like POC images, 
+    #location /media/ {
+    #    alias /home/aptrs/APTRS/APTRS/media/;  # Path to your media files
+    #} 
+
+    location = /favicon.ico { 
+    alias /home/aptrs/APTRS/frontend/dist/favicon.ico;
+    access_log off; 
+    log_not_found off; 
+    
+ }
+
+    ## Server user profile photo
+    location /media/profile/ {
+        alias /home/aptrs/APTRS/APTRS/media/profile/;  # Path to your media files
+ } 
+
+    ## Server Company Logo Images
+    location /media/company/ {
+        alias /home/aptrs/APTRS/APTRS/media/company/;  # Path to your media files
+ }
+
+    ## HTML Report design Images like background images
+    location /media/report/ {
+        alias /home/aptrs/APTRS/APTRS/media/report/;  # Path to your media files
+ } 
+
+    access_log /var/log/nginx/APTRS_access.log;  # Path to access log file
+    error_log /var/log/nginx/APTRS_error.log;   # Path to the error log file
+}
 

 
Let’s enable the file by creating a link from it to the sites-enabled directory, which Nginx reads from during startup:

-
Bash
sudo ln -s /etc/nginx/sites-available/demo.aptrs.com /etc/nginx/sites-enabled/
+
Bash
sudo ln -s /etc/nginx/sites-available/demo.aptrs.com /etc/nginx/sites-enabled/
 

 
Let's verify if any error from the nginx with

-
Bash
sudo nginx -t
+
Bash
sudo nginx -t
 

 If there are no errors we can start the nginx

-
Bash
sudo systemctl restart nginx
+
Bash
sudo systemctl restart nginx
 

 
HTTPS Certificate

 
Once we have the domain name we can get the CA certificate with certbot using the below command. 

-
Bash
sudo apt install certbot python3-certbot-nginx
-sudo certbot --nginx -d demo.aptrs.com
-sudo systemctl status certbot.timer
-sudo certbot renew --dry-run
+
Bash
sudo apt install certbot python3-certbot-nginx
+sudo certbot --nginx -d demo.aptrs.com
+sudo systemctl status certbot.timer
+sudo certbot renew --dry-run
 

 
 
diff --git a/1.0/search/search_index.json b/1.0/search/search_index.json
index 2ff126d..3e5449f 100644
--- a/1.0/search/search_index.json
+++ b/1.0/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Automated Penetration Testing Reporting System","text":"
APTRS (Automated Penetration Testing Reporting System) is a Python, Django and ViteJS-based automated reporting tool designed for penetration testers and security organizations. This tool streamlines the report generation process by enabling users to create PDF, Docx and Excel reports directly, eliminating the need for manual approaches. Additionally, APTRS offers a systematic way to monitor and manage vulnerabilities within various projects. Keep your penetration testing projects organized and efficient with APTRS.
"},{"location":"API/","title":"API Documentation","text":"
     
  • Postman APIs
    •  
  • Postman API Collection
    •  
  • Swagger
    •  
"},{"location":"Features/","title":"Index","text":"
APTRS offers various features and configurations, including the management of companies, customers, projects, retests, different types of reports, configurations, templates, and more. The Features Documentation provides detailed information on the different setups, features, and use cases.
"},{"location":"Features/Users/users/","title":"User Management in APTRS","text":"
APTRS provides robust user management capabilities, allowing you to add, edit, and delete users. Each user can log in to the APTRS platform using their credentials, and they have the option to set a profile photo through the Edit Profile feature. In version 1.0, users are also able to change their passwords.
 
"},{"location":"Features/Users/users/#user-types","title":"User Types","text":"
There are two types of users in APTRS:
 
     
  1. Admin Users: Admin users have elevated permissions and can perform administrative tasks, including managing user accounts and configurations.
    2.  
  2. Non-Admin Users: Non-admin users have restricted access and can perform tasks based on the permissions and groups assigned to them.
    3.  
 
All users can log in and perform tasks according to their assigned permissions and groups. 
 
Info
 
For detailed information on permissions and groups, please refer to the Permissions and Groups section.
"},{"location":"Features/Users/users/#user-classification","title":"User Classification","text":"
Users are classified into two categories:
 
     
  1. Internal Users (Staff Users): By default, all users added to the system are marked as staff users, indicating they are internal users of the APTRS.
    2.  
  2. External Users (Non-Staff Users): External users are designated as non-staff users. For details on managing non-staff users, please refer to the Customer section.
    3.  
 
This structured approach to user management ensures that you can effectively manage access levels and user capabilities within the APTRS platform.
"},{"location":"Features/Users/users/#important-note-on-deleting-users","title":"Important Note on Deleting Users","text":"
All projects in APTRS must have an owner. Deleting a user will cause errors, as projects assigned to that user will no longer have an owner. If you need to disable a user\u2019s account, it is recommended to set the account to \"inactive\" rather than deleting it. If you choose to delete the user, be aware that you will need to manually reassign ownership of all the projects associated with that user to avoid issues.
"},{"location":"Features/company/company/","title":"Company Management in APTRS","text":"
APTRS allows you to add and manage companies, with two types of companies supported: Internal Companies and External (Non-Internal) Companies.
 
"},{"location":"Features/company/company/#internal-companies","title":"Internal Companies","text":"
APTRS assumes that your company, the one deploying and using APTRS, is the internal company. When you deploy APTRS for the first time, an internal company is automatically created. This company is assigned to you and cannot be deleted or replaced. However, you can rename it to reflect your actual company name.
 
Key details about internal companies:
 
     
  • Internal Company Setup: The internal company is auto-created during the initial setup, and no additional internal companies can be added afterward.
    •  
  • User Assignment: All users added through the User Management page will automatically be part of the internal company.
    •  
  • Reports: Users and data from the internal company will be reflected in your reports as staff or internal users.
    •  
"},{"location":"Features/company/company/#external-non-internal-companies","title":"External (Non-Internal) Companies","text":"
All companies manually added after the initial setup are classified as External Companies. These are typically client companies or third-party organizations.
 
Key details about external companies:
 
     
  • User Management: You cannot add users to external companies through the User Management page. Any user added through this page will be assigned as a staff member of the internal company.
    •  
  • Assigning Users to External Companies: To assign users to external companies, you need to go through the Customer section, which manages external users.
    •  
  • Projects: You can create projects for both internal and external companies, allowing you to track and manage work for client companies separately from your own.
    •  
 
This setup ensures a clear distinction between your internal users and external client companies, making it easier to manage access, projects, and reports within APTRS.
 
Warning
 
Deleting a company will also delete all associated users. Make sure to reassign or handle any users before deleting a company.
"},{"location":"Features/company/customer/","title":"Customer Management in APTRS","text":"
Customers in APTRS are external users who belong to external (non-internal) companies. You can manage these users from the Customer page, where external users are added and tracked, and they are included in reports as customer users.
 
"},{"location":"Features/company/customer/#adding-customers","title":"Adding Customers","text":"
When adding a customer, you will need to provide the following information:
 
     
  • Email: The customer's email address.
    •  
  • Company: The external company they belong to.
    •  
  • Password: A password is required as part of the future functionality.
    •  
 
Though passwords are required during customer creation, as of version 1.0, external users do not yet have access to login, API, or dashboard features. These features are planned for future releases, where customers will be able to log into the APTRS dashboard, view ongoing and past projects, download reports, and more.
 
This allows APTRS to lay the groundwork for future functionality while managing customer data and ensuring they are accurately represented in reports.
"},{"location":"Features/configuration/configuration/","title":"Configuration","text":"
The Configuration section allows admin users or users with the Manage Configurations permission to add and manage various settings. In APTRS, users can define Project Types, such as \"Mobile Application Testing,\" which are used when creating projects and are also referenced in PDF and DOCX reports. Multiple project types can be added to suit different testing needs.
 
In addition to project types, users can also create Report Standards. When generating a report, users are required to select the applicable testing standard, such as OWASP for web application testing. Users can add additional standards here, which can then be used in the generated reports.
 
"},{"location":"Features/dashboard/dashboard/","title":"Dashboard","text":"
The Dashboard provides a personalized view of projects based on the logged-in user\u2019s ownership and project status. Unlike the Projects View Page, which lists all projects within APTRS, the Dashboard only displays projects where the logged-in user is the owner and the project is not marked as completed. The Dashboard shows projects with the following statuses: Delay, In Progress, or Upcoming, as long as the user is the owner of those projects.
 
In addition to active or upcoming projects, the Dashboard also displays completed projects if the project has an active retest. Even if a project is marked as completed, it will be shown in the Dashboard if it has any upcoming, in-progress, or delayed retests where the logged-in user is the owner of the retest task.
 
This also applies in cases where the user is the owner of the retest task for a completed project, even if the user is not the owner of the original project. In such cases, the project will still appear on the Dashboard, allowing the user to view and manage their active retest tasks.
 
"},{"location":"Features/permission/permission/","title":"Groups and Permissions in APTRS","text":"
APTRS uses permissions to control access to certain APIs and restrict features to specific users. To streamline this process, APTRS allows you to create groups and assign permissions to those groups. Once a group is created, you can assign users to one or more groups. A user assigned to multiple groups will inherit all the permissions from those groups.
 
"},{"location":"Features/permission/permission/#how-permissions-work","title":"How Permissions Work","text":"
Permissions are pre-defined within APTRS to regulate access to various functionalities. These permissions cannot be modified or created from the user interface, as they are hard-coded in the backend. However, you can create custom groups and assign these predefined permissions to the groups. When users are assigned to a group, they will automatically gain all the permissions associated with that group.
"},{"location":"Features/permission/permission/#admin-users-and-permissions","title":"Admin Users and Permissions","text":"
Admin users in APTRS are not restricted by permissions or group assignments. This means that even if an admin user has no group assigned or is assigned to a group with limited permissions, they will still have full access to all features and APIs in the system. Admin users are always granted full control, regardless of group membership or assigned permissions.
"},{"location":"Features/permission/permission/#default-groups","title":"Default Groups","text":"
When you first deploy APTRS, several default groups are created with specific permissions. The most important groups are Project Manager and Manager. These groups are crucial for report generation, as they are used to add project manager and manager details to reports.
 
While you can edit the permissions assigned to these groups, it is important to retain the group names (\"Project Manager\" and \"Manager\") if you want APTRS to correctly include project manager and manager details in the reports. Removing or renaming these groups may cause issues with report generation and prevent the correct user details from being added to reports.
"},{"location":"Features/permission/permission/#list-of-permissions-as-of-version-10","title":"List of Permissions (as of version 1.0)","text":"
     
  •  
    Manage Users: Users with this permission can add, edit, and delete users, manage groups, and assign permissions to groups. They can also create and delete groups.
     
    •  
  •  
    Manage Projects: Users with this permission can create, edit, and delete projects. They can add vulnerabilities or retests within a project, generate reports, and add scope to projects. By default, users cannot select project or retest owners; projects and retests created by users with this permission will automatically mark the creator as the owner.
     
    •  
  •  
    Assign Projects: This permission allows users to select and assign project or retest owners. Users with this permission can assign any user as the owner of a project or retest.
     
    •  
  •  
    Manage Vulnerability Data: Users with this permission can add, edit, and delete entries in the vulnerability database or templates.
     
    •  
  •  
    Manage Customers: Users with this permission can add, edit, and delete customers.
     
    •  
  •  
    Manage Companies: Users with this permission can add, edit, and delete companies.
     
    •  
  •  
    Manage Configurations: Users with this permission can manage various application configurations.
     
    •  
"},{"location":"Features/project/Vulnerability/","title":"Project Vulnerability","text":"
Each project can have associated vulnerabilities. You can navigate to the Vulnerability tab within a project to manage its vulnerabilities. This tab allows you to add, edit, or remove vulnerabilities specific to that project, providing a dedicated space to document identified security issues, their descriptions, solutions, CVSS scores, and other relevant details.
 
Using the Vulnerability Database, you can quickly import common vulnerabilities with pre-filled information, saving time when adding recurring or well-documented issues across multiple projects.
 
"},{"location":"Features/project/Vulnerability/#adding-vulnerabilities","title":"Adding Vulnerabilities","text":"
APTRS provides multiple ways to add vulnerabilities to a project, offering flexibility in how you manage and document security issues.
 
     
  •  
    Search and Add: This feature allows you to search for vulnerabilities by title or name from the Vulnerability DB or Template. Once you select a vulnerability from the search results, a new entry is created within the project, automatically populated with the title, description, solution, reference link, and CVSS score from the Vulnerability DB. This approach allows for efficient reuse of information with pre-filled details, saving time on repetitive entries.
     
    •  
  •  
    Add New: Selecting \"Add New\" will create a blank vulnerability entry within the project. All fields are initially empty except for the title, which is set to \"New Vulnerability.\" This option is ideal if you need to manually document unique vulnerabilities not in the database. You can fill in all required details such as description, solution, and severity.
     
    •  
  •  
    Upload CSV: This option is designed specifically for importing vulnerabilities from Nessus scan outputs. You can upload a Nessus vulnerability scan CSV report, which APTRS will parse to extract details such as URL or IP, port, title, description, and more. Parsed vulnerabilities are then added directly to the project, saving time on data entry for larger assessments.
     
    •  
"},{"location":"Features/project/Vulnerability/#nessus-csv","title":"Nessus CSV","text":"
This feature can also be used for other, non-Nessus scan reports. As long as the CSV file contains the required columns with matching names, APTRS will process it just like a Nessus report, making it a versatile option for importing vulnerabilities from various sources.
"},{"location":"Features/project/Vulnerability/#required-csv-columns","title":"Required CSV Columns","text":"
To ensure that vulnerabilities are parsed correctly, your CSV file should include the following columns:
 
     
  • Host: The IP address or URL of the affected system.
    •  
  • Port: The network port where the vulnerability was found.
    •  
  • Name: The title of the vulnerability, providing a brief identifier.
    •  
  • Description: A detailed explanation of the vulnerability, including its nature and potential impact.
    •  
  • Solution: Recommended actions or patches to mitigate or resolve the vulnerability.
    •  
  • Risk: The severity level of the vulnerability (e.g., Info, Low, Medium, High, Critical). APTRS uses this to assign a default CVSS score and vector.
    •  
"},{"location":"Features/project/Vulnerability/#cvss-score-and-vector","title":"CVSS Score and Vector","text":"
As of version 1.0, APTRS does not accept CVSS scores and vectors from CSV imports because default Nessus reports do not include them. Instead, APTRS assigns a default CVSS score and vector based on the Risk level provided in the CSV file.
"},{"location":"Features/project/Vulnerability/#default-cvss-scores-and-vectors-cvss-31","title":"Default CVSS Scores and Vectors (CVSS 3.1)","text":"
These default values are automatically assigned based on the risk level when the CSV is parsed:
 Severity Base Score Vector Critical 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H High 7.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L Medium 5.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L Low 3.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N Informational 0.0 CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N 
These defaults ensure consistency in reporting for imported vulnerabilities, even if specific CVSS details aren\u2019t included in the CSV file.
"},{"location":"Features/project/Vulnerability/#vulnerability-instances","title":"Vulnerability Instances","text":"
Each vulnerability in a project is required to have an instance. An instance represents the specific URL, parameter, IP address, and port number of the affected vulnerability. Each instance within a vulnerability can have its own status, allowing for more granular tracking and resolution.
 
"},{"location":"Features/project/Vulnerability/#vulnerability-and-instance-status","title":"Vulnerability and Instance Status","text":"
The status of each vulnerability and its instances is tracked individually to provide clear insights into the resolution progress. Below are the details on how the status is managed and calculated for both vulnerabilities and their instances.
 
The status of a vulnerability and its instances are interconnected. There are three possible statuses for both vulnerabilities and instances:
 
     
  • Vulnerable: The vulnerability or instance has unresolved security issues.
    •  
  • Confirmed Fix: The vulnerability or instance has been resolved and no longer has security issues.
    •  
  • Accepted Risk: The vulnerability or instance remains unresolved, but the customer or client has accepted the associated risk.
    •  
 
These statuses function as follows:
 
     
  1.  
    Changing Vulnerability Status: If you change the status of a vulnerability, all instances associated with that vulnerability will automatically be set to the same status. For example, setting a vulnerability to Accepted Risk will update all instances within that vulnerability to Accepted Risk as well.
     
    2.  
  2.  
    Changing Instance Status: When modifying the status of individual instances within a vulnerability, the overall vulnerability status is recalculated based on its instances' statuses. The rules are as follows:
     
       
    • Confirmed Fix: For a vulnerability to be marked as Confirmed Fix, all instances must be set to Confirmed Fix. Even a single instance with a different status prevents the vulnerability from being marked as Confirmed Fix.
      •  
    • Vulnerable: If any instance is marked as Vulnerable, the entire vulnerability is marked as Vulnerable, regardless of other instances\u2019 statuses.
      •  
    • Accepted Risk: If all instances are marked as Accepted Risk, the vulnerability status will also be set to Accepted Risk.
      •  
     
    3.  
 
In short, for a vulnerability to be considered Confirmed Fix, all instances must be Confirmed Fix. To be marked as Accepted Risk, all instances must have that status. Any instance marked as Vulnerable will cause the vulnerability itself to be marked as Vulnerable.
"},{"location":"Features/project/project-view/","title":"Project View","text":"
APTRS allows users to create and manage projects, which are typically created when conducting a pentest for a company. When setting up a project, you can associate it with a specific company, select multiple internal users as project owners, and define key details such as project type, start and end dates, and a brief description.
 
Once the project is created, you can later add vulnerabilities, generate reports, and track progress within the project. This feature helps organize pentesting efforts efficiently, ensuring clear project ownership and structure.
 
"},{"location":"Features/project/project-view/#project-status","title":"Project Status","text":"
The project status is automatically calculated based on the project\u2019s start and end dates:
 
     
  • Upcoming: If the start date is in the future.
    •  
  • In Progress: If the start date has passed or is today, but the end date is still in the future.
    •  
  • Delayed: If the end date has passed.
    •  
  • Completed: If the project is marked as completed.
    •  
 
If your project is completed, you can manually mark it as Completed from the project summary. To do this, navigate to the project from the project table or dashboard, and you\u2019ll find an option to mark it as completed on the project summary page.
"},{"location":"Features/project/project-view/#project-details","title":"Project Details","text":"
Once a project is created, it is not possible to change the associated company. However, you can still edit other details, such as project type, dates, description, and owners.
"},{"location":"Features/project/project-view/#project-owners","title":"Project Owners","text":"
In Version 1.0, APTRS supports assigning multiple project owners, allowing you to add as many project owners as needed. Assigning or selecting a project owner requires admin privileges or the Assign Projects permission. Otherwise, the user creating the project is automatically added as the project owner.
"},{"location":"Features/project/report/","title":"Project Report","text":"
Once your project is ready, you can generate a report for the identified vulnerabilities. APTRS version 1.0 provides options to generate reports in PDF, Excel, and DOCX formats. Navigate to the report section within the project, select the desired report type and standard, and download the report directly.
 
 
As of version 1.0, the DOCX report generation feature is experimental. It may be removed or enhanced with more customization options in future versions. Once validated for full customization and consistent presentation, this feature will become permanent.
"},{"location":"Features/project/report/#report-customization","title":"Report Customization","text":"
You can customize both the PDF and DOCX reports:
 
     
  • PDF Reports: APTRS uses the WeasyPrint Python library to convert HTML into PDF. You can modify the HTML and CSS files used in report generation to match your requirements. 
    •  
  • DOCX Reports: APTRS leverages the python-docxtpl library to create DOCX files. The CKEditor WYSIWYG editor is used for entering vulnerability and project details. CKEditor\u2019s HTML output is then converted into DOCX format using the html2docx library, and integrated with docxtpl to generate the final report.
    •  
 
The HTML and DOCX report templates are available here: - HTML and DOCX Report Templates
 
CSS files for HTML-to-PDF reports can be customized here: - CSS for PDF Reports
"},{"location":"Features/project/report/#report-limitations","title":"Report Limitations","text":"
     
  • PDF Reports: APTRS uses the WeasyPrint Python library to generate PDF reports. However, WeasyPrint does not support JavaScript execution, which limits the ability to include custom, interactive charts directly within the PDF. Instead, APTRS generates charts using a Python library and embeds them as static images in the PDF. This approach restricts customization of charts via HTML and CSS.
    •  
  • DOCX Reports: APTRS generates DOCX reports using a combination of python-docx, python-docxtpl, and html2docx. While python-docxtpl enables dynamic content insertion into documents, it does not support updating or dynamically modifying charts. As a result, charts included in DOCX reports cannot be automatically updated with dynamic values by APTRS.
    •  
"},{"location":"Features/project/retest/","title":"Project Retest","text":"
Each project can have a retest task created and assigned to a user. Similar to a project, each retest includes a start and end date and has a designated retest owner. Retests allow you to specify the revalidation of the project\u2019s vulnerabilities, ensuring that fixes have been applied as expected. Within a project, users can initiate a retest to start this process.
 
 
Similar to project ownership, the retest owner is automatically set to the user creating the retest if they do not have admin privileges or the Assign Projects permission. Users with admin access or Assign Projects permission can select the retest owner. Once a retest task is created, it cannot be edited, though you can still delete the retest task if needed.
"},{"location":"Features/project/retest/#validation","title":"Validation","text":"
     
  • Project Completion Requirement: A retest task cannot be created if the project is not marked as completed. Retests are only applicable to projects that have been fully executed, as retests aim to validate resolved vulnerabilities. Therefore, a project must be completed before any retest can be initiated.
    •  
  • Single Active Retest Restriction: Even if the project is completed, you cannot create a new retest task if there is an existing retest task that is not marked as completed. Only one active retest can be associated with a project at a time.
    •  
"},{"location":"Features/project/scope/","title":"Project Scope","text":"
Each project includes scopes, allowing you to define the list of IPs, URLs, or application names that are part of the engagement. Starting from version 1.0, each project can have multiple scopes. Within the project page, you can navigate to the Scope section to manage the specific scope of the project.
 
"},{"location":"Features/vulnerabilityDB/vulnerability/","title":"Vulnerability DB (or Template)","text":"
The Vulnerability DB or Template feature in APTRS allows you to add and manage a database of vulnerabilities that can be reused across different projects. When adding a vulnerability to a project, you can specify all necessary details such as the title, description, solution, CVSS score, and more.
 
If you encounter the same vulnerability in multiple projects, such as IDOR or SQL Injection, the Vulnerability DB allows you to save time by reusing the same information without needing to write it again for each project. This helps streamline reporting and ensures consistency across projects.
 
By creating templates for common vulnerabilities, you can easily import them when adding vulnerabilities to new projects, reducing redundant work and improving efficiency.
 
"},{"location":"custom-report/docx/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/docx/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
     
  •  
    Description: 
     
    This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
     
    •  
  •  
    Usage Example:
     Python
    Company Who DID the Pentest: {{ mycompany }}\n
     
    •  
"},{"location":"custom-report/docx/company-user/#2-project-manager-users","title":"2. Project Manager Users","text":"
     
  •  
    Description:
     
    This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
     
    •  
  •  
    Usage Example:
     Python
    Project Managers:\n\n        {% for user in projectmanagers %}\n            {{ user.full_name }}  {{ user.position }} {{ user.email }}\n        {% endfor %}\n
     
    •  
"},{"location":"custom-report/docx/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
     
  •  
    Description:
     
    This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
     
    •  
  •  
    Usage Example:
     Text Only
        Customer Users:\n\n        {% for user in customeruser %}\n            {{ user.full_name }} {{ user.position }} {{ user.email }}\n        {% endfor %}\n
     
    •  
"},{"location":"custom-report/docx/docx/","title":"Docx","text":"
APTRS provides the ability to generate detailed DOCX reports using customizable templates. You can use Jinja2 template tags within your .docx templates to dynamically populate project and vulnerability data. This guide explains how to customize your template and use available context variables.
"},{"location":"custom-report/docx/docx/#template-location","title":"Template Location","text":"
The default template is located at: /APTRS/templates/report.docx
 
You can replace this file with your custom .docx template while keeping the required placeholders intact.
"},{"location":"custom-report/docx/docx/#using-template-tags","title":"Using Template Tags","text":"
The .docx template uses Jinja2 syntax for placeholders and loops. Below are some examples:
"},{"location":"custom-report/docx/docx/#placeholders","title":"Placeholders","text":"
     
  • Syntax: {{ variable_name }}
    •  
  • Example: To display the project name, use: {{ project.name }}
    •  
"},{"location":"custom-report/docx/docx/#loops","title":"Loops","text":"
     
  • Syntax: {% for item in items %}...{% endfor %}
    •  
  • Example: To list all vulnerabilities:
    •  
 Python
{% for vulnerability in vulnerabilities %}\n\n{{ vulnerability.vulnerabilityname }} (CVSS: {{ vulnerability.cvssscore }}) {% endfor %}\n
"},{"location":"custom-report/docx/docx/#conditional-statements","title":"Conditional Statements","text":"
     
  • Syntax: {% if condition %}...{% else %}...{% endif %}
    •  
  • Example: To check if a project has vulnerabilities:
    •  
 Python
{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n
"},{"location":"custom-report/docx/docx/#available-context-variables","title":"Available Context Variables","text":"Variable Description project The project object for which the report is being generated. Contains all project details. owners User details of All Project Owners project_exception Project Exceptions project_description Project Description vulnerabilities Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). mycomany The name of the internal (your company) company. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. projectscope Queryset of all project scopes for the project. totalretest List of retest schedules and owners. totalvulnerability Total count of vulnerabilities for the project. Report_type The type of report being generated (e.g., Audit, Re-Audit). standard The standard or methodology being used for the report. currentdate Get Current Date if needed in the report page_break Allows you to add page break in the docx report such as page break after each vulnerability details new_line Allows you to add a new line if needed"},{"location":"custom-report/docx/docx/#docx-formatting-with-jinja2","title":"Docx Formatting with Jinja2","text":"
By default, Jinja2 adds blank lines with conditions or loops, which can be problematic for Docx formatting. Unlike HTML, where empty lines have minimal impact, in Docx, this can lead to extra rows in tables or increased table width.
 
APTRS uses the docxtpl library, based on Python-docx and Jinja2, for template-based rendering. To reduce blank lines, you can use Jinja2's whitespace control.
 
However, this method doesn't always work flawlessly; it may inadvertently remove important elements like tables along with extra spaces. A simpler solution can involve using a single line of code.
 
You can modify the code like this:
 Python
##Instead of new line for code\n{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n\n\n## you can change it to like this on a single line \n\n{% if vulnerabilities %} Vulnerabilities are present. {% else %} No vulnerabilities found. {% endif %}\n
"},{"location":"custom-report/docx/docx/#color-and-conditions","title":"Color and Conditions","text":"
Each severity level in the report is represented by different colors: low or informational is often green or light blue, while high severity is red. Status can also be color-coded, with fixed vulnerabilities in green and open ones in red or orange.
 
In HTML reports, you can add severity values to the tag's class attribute and create CSS to apply the colors.
 
For DOCX reports, colors cannot be applied to undefined elements, limiting customization. To assign colors based on severity\u2014like red for critical and orange for high\u2014include them directly in the conditional statements within your DOCX template.
 Python
{% if severity == 'Critical' %} severity with red color. {% elif severity == 'Low' %} severity with green color. {% endif %}\n
 
 
Note
 
Adding Jinja2 White Space control to this will remove the color.
 
What if instead of just color for the text, we want to add color for the cell in the table like below  
 Name Status Severity SQL Injection Vulnerable Confirm Fixed 
We can do that as well with cellbg in the table, with hex color code like below:
 Python
{% cellbg 'FF491C' if vulnerability.vulnerabilityseverity== 'Critical' else 'F66E09' if vulnerability.vulnerabilityseverity== 'High' else 'FBBC02' if vulnerability.vulnerabilityseverity== 'Medium' else '20B803' if vulnerability.vulnerabilityseverity== 'Low' else '3399FF' %}{{ vulnerability.vulnerabilityseverity}}\n
 
"},{"location":"custom-report/docx/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/docx/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
     
  • Description:   Provides the total count of vulnerabilities associated with a project.
    •  
  • Usage Example:   You can display the total number of vulnerabilities for the project.
    •  
 Python
Total Vulnerabilities: {{ totalvulnerability }}\n
"},{"location":"custom-report/docx/other/#2-report-type","title":"2. Report Type","text":"
     
  • Description:   Specifies the type of report being generated. This can include types like \"Audit\" or \"Re-Audit\".
    •  
  • Usage Example:   Show the type of the report (Audit or Re-Audit).
    •  
 Python
  Report Type: {{ Report_type }}\n
"},{"location":"custom-report/docx/other/#3-report-standard","title":"3. Report Standard","text":"
     
  • Description:   The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
    •  
  • Usage Example:   Display the methodology or standard used in the vulnerability report.
    •  
 Python
  Report Standard: {{ standard|join(', ') }} \n
"},{"location":"custom-report/docx/other/#4-current-date","title":"4. Current Date","text":"
     
  •  
    Description:   Get the current date if needed in the report.
     
    •  
  •  
    Usage Example: Python
    Report Generated On: {{ currentdate }}   \n# OR\n{{ currentdate.strftime('%B %d, %Y') }}\n
     
    •  
"},{"location":"custom-report/docx/other/#5-page-break","title":"5.  Page Break","text":"
     
  •  
    Description:    Allows you to add a page break in the DOCX report, such as after each vulnerability's details.
     
    •  
  •  
    Usage Example: Python
      {% if vulnerability %}\n  {{ page_break }}\n  {% endif %}\n
     
    •  
"},{"location":"custom-report/docx/other/#6-new-line","title":"6. New Line","text":"
     
  •  
    Description:    Allows you to add a new line if needed in the report.
     
    •  
  •  
    Usage Example: Python
      Vulnerability Details:  \n  CVSS Score{{ new_line }} 8.8\n
     
    •  
"},{"location":"custom-report/docx/project/","title":"Project","text":""},{"location":"custom-report/docx/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report Docx, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/docx/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
     
  1.  
    project.name 
     
       
    • Represents the name of the project.  
      •  
    • Example usage in HTML: Python
      Project Name: {{ project.name }}\n
      •  
     
    2.  
  2.  
    project.companyname 
     
       
    • A foreign key to the Company model, representing the company associated (Customer Company) with the project.  
      •  
    • Example usage: Python
      Company Name: {{ project.companyname.name }}\n
      •  
     
    3.  
  3.  
    project_exception 
     
       
    • A detailed description of the project.  
      •  
    • Example usage: Python
      Description: {{p project_exception}}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    4.  
  4.  
    project.projecttype 
     
       
    • Specifies the type of project.  
      •  
    • Example usage: Python
      Project Type: {{ project.projecttype }}\n
      •  
     
    5.  
  5.  
    project.startdate 
     
       
    • The start date of the project.  
      •  
    • Example usage: Python
      Start Date: {{ project.startdate }}\n
      •  
    • You can also modify the date format      Python
          Project Start Date: {{ project.startdate.strftime(\"%d/%m/%Y\") }}\n
      •  
     
    6.  
  6.  
    project.enddate 
     
       
    • The end date of the project.  
      •  
    • Example usage: Python
      <End Date: {{ project.enddate }}\n
      •  
    • You can also modify the date format      Python
          Project End Date: {{project.enddate.strftime(\"%d/%m/%Y\") }}\n
      •  
     
    7.  
  7.  
    project.testingtype 
     
       
    • The type of testing performed for the project (e.g., White Box, Black Box).  
      •  
    • Example usage: Python
      Testing Type: {{ project.testingtype }}\n
      •  
     
    8.  
  8.  
    project_exception 
     
       
    • Notes or exceptions for the project, if any.  
      •  
    • Example usage: Python
      Exceptions: {{p project_exception }}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
    • In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions.   Python
      {% if project_exception %}\nExceptions: {{p project_exception }}\n{% endif %}\n
      •  
     
    9.  
  9.  
    project.owner 
     
       
    • Note: This is not available, due to issues with the method provided by django to loop many to many database relation, it does not work with the jinja2. 
      •  
     
    10.  
  10.  
    project.status 
     
       
    • The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).  
      •  
    • Example usage: Python
      Status: {{ project.status }}\n
      •  
     
    11.  
 
In order to get Project owner details, APTRS provide a seperate context and tag owners which contain user details for project owners. In order to use it you have to loop through details like below:
 Python
      {% for owner in owners %}\n        {{ owner.full_name}}\n        {{ owner.email}}\n        {{ owner.position}}\n        {{ owner.number}}\n      {% endfor %}\n
"},{"location":"custom-report/docx/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status. 
 
     
  • Usage Example:   You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
    •  
 Python
  Project Retests:\n\n      {% for retest in totalretest %}\n          {{ retest.startdate }}  {{ retest.enddate }} | Status: {{ retest.status }}\n\n                  {% for owner in retest.owners %}\n                      {{ owner }}\n                  {% endfor %}\n\n      {% endfor %}\n
 
Note
 
The {{ owner }} will only show the full_name of the owner, as of now its limited to full name only.
 
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
 HTML
{% if Report_type == 'Re-Audit' %}\n  Project Retests:\n\n      {% for retest in totalretest %}\n          {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n                {% for owner in retest.owners %}\n                      {{ owner }}\n                  {% endfor %}\n\n      {% endfor %}\n\n{% endif %}\n
"},{"location":"custom-report/docx/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
 
     
  • Usage Example:
    •  
 Python
Project Scope:\n\n    {% for scope in projectscope %}\n        {{ scope.scope }}  {{ scope.description }}\n    {% endfor %}\n</ul>\n
"},{"location":"custom-report/docx/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/docx/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. APTRS provide {{vulnerabilities}} tag with list of all vulnerabilities and its instances. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/docx/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
     
  1.  
    vulnerability.vulnerabilityname 
     
       
    • The name of the vulnerability (e.g., \"SQL Injection\").  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nVulnerability Name: {{ vulnerability.vulnerabilityname }}\n{% endfor %}\n
      •  
     
    2.  
  2.  
    vulnerability.vulnerabilityseverity 
     
       
    • The severity of the vulnerability (e.g., \"High\", \"Medium\").  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nSeverity: {{ vulnerability.vulnerabilityseverity }}\n{% endfor %}\n
      •  
     
    3.  
  3.  
    vulnerability.cvssscore 
     
       
    • The CVSS score associated with the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCVSS Score: {{ vulnerability.cvssscore }}\n{% endfor %}\n
      •  
     
    4.  
  4.  
    vulnerability.cvssvector 
     
       
    • The CVSS vector associated with the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCVSS Vector: {{ vulnerability.cvssvector }}\n{% endfor %}\n
      •  
     
    5.  
  5.  
    vulnerability.status 
     
       
    • The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nStatus: {{ vulnerability.status }}\n{% endfor %}\n
      •  
     
    6.  
  6.  
    vulnerability.vulnerabilitydescription 
     
       
    • A description of the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nDescription: {{p vulnerability.vulnerabilitydescription }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    7.  
  7.  
    vulnerability.POC 
     
       
    • The proof of concept (POC) for the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nPOC: {{p vulnerability.POC }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    8.  
  8.  
    vulnerability.vulnerabilitysolution 
     
       
    • The recommended solution for the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nSolution: {{p vulnerability.vulnerabilitysolution }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    9.  
  9.  
    vulnerability.vulnerabilityreferlnk 
     
       
    • A reference link related to the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nReference Link: {{p vulnerability.vulnerabilityreferlnk }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    10.  
  10.  
    vulnerability.created 
     
       
    • The timestamp when the vulnerability was created.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCreated: {{ vulnerability.created }}\n{% endfor %}\n
      •  
     
    11.  
  11.  
    vulnerability.created_by 
     
       
    • The user who created the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCreated By: {{ vulnerability.created_by.username }}\n{{ vulnerability.created_by.full_name }}\n{% endfor %}\n
      •  
    • Similar to project owner, you can use other filed as well  like email, number or postion etc.
      •  
     
    12.  
  12.  
    vulnerability.last_updated_by 
     
       
    • The user who last updated the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nLast Updated By: {{ vulnerability.last_updated_by.username }}\n{{ vulnerability.last_updated_by.full_name }}\n{% endfor %}\n
      •  
     
    13.  
  13.  
    vulnerability.instances_data 
     
       
    • Acess all instaces of the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\n\n      {for instance in vulnerability.instances_data %}\n      ## This give all instances for vulnerabiltiy in current loop\n\n        URL: {{ instance.URL }}\n        Parameter: {{ instance.Parameter }}\n        Parameter: {{ instance.Status }}\n\n      {% endfor %}\n\n{% endfor %}\n
      •  
     
    14.  
"},{"location":"custom-report/docx/vulnerability/#example","title":"Example","text":"Python
{% for vulnerability in vulnerabilities %}\n\n    Vulnerability Name: {{ vulnerability.vulnerabilityname }}\n\n    Severity: {{ vulnerability.vulnerabilityseverity }}\n\n    CVSS Score: {{ vulnerability.cvssscore }}\n\n    CVSS Vector: {{ vulnerability.cvssvector }}\n\n    Status: {{ vulnerability.status }}\n\n    Description:  \n    {{p vulnerability.vulnerabilitydescription }}\n\n    POC:  \n    {{p vulnerability.POC }}\n\n    Solution:  \n    {{p vulnerability.vulnerabilitysolution }}\n\n    Reference Link:  \n    {{p vulnerability.vulnerabilityreferlnk }}\n\n    Created On: {{ vulnerability.created }}\n\n    Created By:  \n    - Username: {{ vulnerability.created_by.username }}  \n    - Full Name: {{ vulnerability.created_by.full_name }}\n    - Email: {{ vulnerability.created_by.email }}\n    - Number: {{ vulnerability.created_by.number }}\n\n    Last Updated By:  \n    - Username: {{ vulnerability.last_updated_by.username }}\n    - Full Name: {{ vulnerability.last_updated_by.full_name }}\n    - Email: {{ vulnerability.last_updated_by.email }}\n    - Number: {{ vulnerability.last_updated_by.number }}\n\n    Instances\n\n      {for instance in vulnerability.instances_data %}\n\n        URL: {{ instance.URL }}\n        Parameter: {{ instance.Parameter }}\n        Parameter: {{ instance.Status }}\n\n      {% endfor %}\n\n{% endfor %}\n
"},{"location":"custom-report/docx/vulnerability/#reference","title":"Reference","text":"
For reference you can see vulnerabilities tag as below json object
 JSON
vulnerabilities = [\n    {\n        \"project\": \"Project Name or ID\",  \n        \"vulnerabilityname\": \"SQL Injection in Login Page\",\n        \"vulnerabilityseverity\": \"High\",\n        \"cvssscore\": 9.8,\n        \"cvssvector\": \"AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\n        \"status\": \"Vulnerable\",\n        \"vulnerabilitydescription\": \"Converted DOCX content for vulnerability 1 description\",\n        \"POC\": \"Converted DOCX content for vulnerability 1 proof of concept\",\n        \"created\": \"2024-11-20T10:15:30Z\",\n        \"vulnerabilitysolution\": \"Converted DOCX content for vulnerability 1 solution\",\n        \"vulnerabilityreferlnk\": \"Converted DOCX content for vulnerability 1 reference link\",\n        \"created_by\": \"User1\",\n        \"last_updated_by\": \"User2\",\n        \"instances_data\": [\n            {\n                \"URL\": \"https://example.com/vulnerable-endpoint-1\",\n                \"Parameter\": \"user_id\",\n                \"Status\": \"Open\"\n            },\n            {\n                \"URL\": \"https://example.com/another-endpoint-1\",\n                \"Parameter\": \"\",\n                \"Status\": \"Closed\"\n            }\n        ]\n    },\n    {\n        \"project\": \"Project Name or ID\",  \n        \"vulnerabilityname\": \"Cross-Site Scripting in Search Page\",\n        \"vulnerabilityseverity\": \"Medium\",\n        \"cvssscore\": 6.5,\n        \"cvssvector\": \"AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N\",\n        \"status\": \"Vulnerable\",\n        \"vulnerabilitydescription\": \"Converted DOCX content for vulnerability 2 description\",\n        \"POC\": \"Converted DOCX content for vulnerability 2 proof of concept\",\n        \"created\": \"2024-11-19T14:10:45Z\",\n        \"vulnerabilitysolution\": \"Converted DOCX content for vulnerability 2 solution\",\n        \"vulnerabilityreferlnk\": \"Converted DOCX content for vulnerability 2 reference link\",\n        \"created_by\": \"User3\",\n        \"last_updated_by\": \"User4\",\n        \"instances_data\": [\n            {\n                \"URL\": \"https://example.com/vulnerable-endpoint-2\",\n                \"Parameter\": \"session_id\",\n                \"Status\": \"Open\"\n            },\n            {\n                \"URL\": \"https://example.com/another-endpoint-2\",\n                \"Parameter\": \"order_id\",\n                \"Status\": \"Closed\"\n            }\n        ]\n    }\n]\n
"},{"location":"custom-report/pdf/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/pdf/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
     
  •  
    Description: 
     
    This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
     
    •  
  •  
    Usage Example:
     HTML
    <p>Company: {{ mycompany }}</p>\n
     
    •  
"},{"location":"custom-report/pdf/company-user/#2-project-manager-users","title":"2. Project Manager Users","text":"
     
  •  
    Description:
     
    This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
     
    •  
  •  
    Usage Example:
     HTML
    <h3>Project Managers:</h3>\n    <ul>\n        {% for user in projectmanagers %}\n            <li>{{ user.full_name }} - {{ user.position }}</li>\n        {% endfor %}\n    </ul>\n
     
    •  
"},{"location":"custom-report/pdf/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
     
  •  
    Description:
     
    This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
     
    •  
  •  
    Usage Example:
     HTML
        <h3>Customer Users:</h3>\n    <ul>\n        {% for user in customeruser %}\n            <li>{{ user.full_name }} - {{ user.position }}</li>\n        {% endfor %}\n    </ul>\n
     
    •  
"},{"location":"custom-report/pdf/context-variable/","title":"Context Variable","text":"
This document describes how to customize the HTML templates used to generate PDF reports using the GetHTML function in your Django application. Below are the available context variables that can be used in the HTML templates and their respective details.
"},{"location":"custom-report/pdf/context-variable/#context-variables","title":"Context Variables","text":"
The following context variables are passed to the HTML template (report.html) during PDF generation. Users can use these variables to dynamically customize the content of the PDF report.
 Variable Name Description project The project object for which the report is being generated. Contains all project details. vuln Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). instances Queryset of all vulnerable instances associated with the project. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. mycomany The name of the internal (your company) company. projectscope Queryset of all project scopes for the project. totalretest Queryset of all retests for the project. totalvulnerability Total count of vulnerabilities for the project. ciritcal Count of vulnerabilities with severity \"Critical\". high Count of vulnerabilities with severity \"High\". medium Count of vulnerabilities with severity \"Medium\". low Count of vulnerabilities with severity \"Low\". info Count of vulnerabilities with severity \"Informational\" or \"None\". standard The standard or methodology being used for the report. Report_type The type of report being generated (e.g., Audit, Re-Audit). pie_chart Rendered pie chart data showing the vulnerability distribution by severity."},{"location":"custom-report/pdf/context-variable/#how-to-customize-templates","title":"How to Customize Templates","text":"
     
  1.  
    Locate the HTML Template: 
     
       
    • The report template is located at templates/*. You can modify this file or create a new one for different report types.
      •  
     
    2.  
  2.  
    Use Context Variables: 
     
       
    • Insert the context variables into the template using Django's template syntax. For example:     HTML
      <h1>Vulnerability Report for {{ project.name }}</h1>\n<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n<p>Critical Issues: {{ ciritcal }}</p>\n<p>High Severity Issues: {{ high }}</p>\n
      •  
     
    3.  
  3.  
    Dynamic Content:
     
       
    • Use loops and conditionals to dynamically render data. For example:     HTML
      <ul>\n{% for vuln in vuln %}\n    <li>{{ vuln.vulnerabilityname }} - Severity: {{ vuln.vulnerabilityseverity }}</li>\n{% endfor %}\n</ul>\n
      •  
     
    4.  
  4.  
    Styling and Charts:
     
       
    • Use {{ pie_chart|safe }} to embed the rendered pie chart in the HTML. Ensure that the safe filter is applied to include raw HTML safely.
      •  
     
    5.  
"},{"location":"custom-report/pdf/context-variable/#example-template-usage","title":"Example Template Usage","text":"
Here\u2019s a sample section of the report.html template:
 HTML
<!DOCTYPE html>\n<html>\n<head>\n    <title>{{ project.name }} Vulnerability Report</title>\n</head>\n<body>\n    <h1>{{ mycomany }} - Vulnerability Report</h1>\n    <h2>Project: {{ project.name }}</h2>\n    <p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n    <p>Critical Issues: {{ ciritcal }}</p>\n    <p>High Severity Issues: {{ high }}</p>\n    <p>Medium Severity Issues: {{ medium }}</p>\n    <p>Low Severity Issues: {{ low }}</p>\n    <p>Informational Issues: {{ info }}</p>\n\n    <h3>Vulnerability Breakdown</h3>\n    {{ pie_chart|safe }}\n\n    <h3>Vulnerabilities</h3>\n    <ul>\n        {% for v in vuln %}\n            <li>{{ v.vulnerabilityname }} - Severity: {{ v.vulnerabilityseverity }}</li>\n        {% endfor %}\n    </ul>\n</body>\n</html>\n
"},{"location":"custom-report/pdf/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/pdf/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
     
  • Description:   Provides the total count of vulnerabilities associated with a project.
    •  
  • Usage Example:   You can display the total number of vulnerabilities for the project.
    •  
 HTML
<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n
"},{"location":"custom-report/pdf/other/#2-severity-count","title":"2. Severity Count","text":"
     
  • Description:   Shows the count of vulnerabilities that have a severity of Critical or High, Medium, Low, None.
    •  
  • Usage Example:   You can display the severity count.
    •  
 HTML
  <p>Critical Vulnerabilities: {{ critical }}</p>\n  <p>High Vulnerabilities: {{ high }}</p>\n  <p>Medium Vulnerabilities: {{ medium }}</p>\n  <p>Low Vulnerabilities: {{ low }}</p>\n  <p>Informational Vulnerabilities: {{ info }}</p>\n
"},{"location":"custom-report/pdf/other/#3-report-standard","title":"3. Report Standard","text":"
     
  • Description:   The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
    •  
  • Usage Example:   Display the methodology or standard used in the vulnerability report.
    •  
 HTML
  <p>Report Standard: {{ standard|join:\", \" }}</p>\n
"},{"location":"custom-report/pdf/other/#4-report-type","title":"4. Report Type","text":"
     
  • Description:   Specifies the type of report being generated. This can include types like \"Audit\" or \"Re-Audit\".
    •  
  • Usage Example:   Show the type of the report (Audit or Re-Audit).
    •  
 HTML
  <p>Report Type: {{ Report_type }}</p>\n
"},{"location":"custom-report/pdf/other/#5-chart-image","title":"5. Chart Image","text":"
     
  • Description:   This variable holds the rendered data for a pie chart showing the distribution of vulnerabilities by severity.
    •  
  • Usage Example:   Use this to display a pie chart visualizing vulnerability severity distribution.
    •  
 HTML
  <div>{{ pie_chart|safe }}</div>\n
"},{"location":"custom-report/pdf/pdf/","title":"Customized PDF Report Documentation","text":"
APTRS uses the WeasyPrint library to generate PDF reports from HTML and CSS. The Django template engine dynamically passes data to the HTML template using context variables. 
"},{"location":"custom-report/pdf/pdf/#how-it-works","title":"How It Works","text":"
The system is designed so you don\u2019t need to edit the Django code that handles report generation unless you are familiar with Django and Python. The recommended approach is to customize the layout and styling by modifying the HTML and CSS files provided with the project.
"},{"location":"custom-report/pdf/pdf/#file-structure-for-customization","title":"File Structure for Customization","text":"
Within the project root directory, there is a subdirectory named APTRS. This contains the following important folders for report customization:
 
     
  1.  
    Static Folder:  
     
       
    • Located inside the APTRS directory.  
      •  
    • Contains a CSS subfolder where all CSS files for the report are stored.  
      •  
    • Includes predefined styles that you can customize to adjust the appearance of the report.
      •  
     
    2.  
  2.  
    Templates Folder:  
     
       
    • Located in the same directory as the static folder.  
      •  
    • Contains all the HTML templates used for generating reports.  
      •  
    • Templates are modular, with the main report layout in report.html and additional reusable components loaded using Django's {% include %} tag.
      •  
     
    3.  
"},{"location":"custom-report/pdf/pdf/#key-files-for-customization","title":"Key Files for Customization","text":"
     
  1.  
    report.html:
     
       
    • The main HTML file for the report.  
      •  
    • Includes the overall structure, head tags, and references to CSS files.  
      •  
    • Dynamically includes other HTML components for better modularity.
      •  
     
    2.  
  2.  
    report-page.css:
     
       
    • The primary CSS file applied to all report pages.  
      •  
    • Handles global styles such as font loading, page numbering, table styles, and default styles for HTML tags.  
      •  
    • Defines general formatting applied across the entire report.
      •  
     
    3.  
  3.  
    Component Files:
     
       
    • Each HTML file has a corresponding CSS file for specific styles.
      •  
    • For example, styles specific to an HTML section like vulnerability.html will be defined in vulnerability.css.
      •  
    • This structure ensures easy identification and modification of styles tied to specific sections.
      •  
     
    4.  
"},{"location":"custom-report/pdf/pdf/#fonts","title":"Fonts","text":"
The project uses the Fira Sans font by default, stored in the static/fonts folder. You can:
 
     
  • Add new fonts to the fonts folder.
    •  
  • Update the CSS in the report-page.css file to use your fonts.
    •  
"},{"location":"custom-report/pdf/pdf/#customization-tips","title":"Customization Tips","text":"
     
  • Modify HTML files to change content layout, add new sections, or reorder components.
    •  
  • Edit CSS files to change colors, fonts, or styles for specific sections.
    •  
  • Use the modular structure to quickly locate and modify styles for individual components.
    •  
  • For global styles or formatting (e.g., page numbers, headers, footers), update report-page.css.
    •  
"},{"location":"custom-report/pdf/pdf/#important-notes","title":"Important Notes","text":"
     
  • Avoid editing the Django code unless necessary, as it handles the logic for passing variables and generating the PDF.
    •  
  • All changes to the static files (CSS) or templates (HTML) will reflect in the next report generated.
    •  
"},{"location":"custom-report/pdf/project/","title":"Project","text":""},{"location":"custom-report/pdf/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report HTML, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/pdf/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
     
  1.  
    project.name 
     
       
    • Represents the name of the project.  
      •  
    • Example usage in HTML: HTML
      <h1>Project Name: {{ project.name }}</h1>\n
      •  
     
    2.  
  2.  
    project.companyname 
     
       
    • A foreign key to the Company model, representing the company associated (Customer Company) with the project.  
      •  
    • Example usage: HTML
      <p>Company Name: {{ project.companyname.name }}</p>\n
      •  
     
    3.  
  3.  
    project.description 
     
       
    • A detailed description of the project.  
      •  
    • Example usage: HTML
      <p>Description: {{project.description|clean_html}}</p>\n
      •  
    • It uses CKeditor HTML data, using |clean_html allow to render html data securely instead of as text.
      •  
     
    4.  
  4.  
    project.projecttype 
     
       
    • Specifies the type of project.  
      •  
    • Example usage: HTML
      <p>Project Type: {{ project.projecttype }}</p>\n
      •  
     
    5.  
  5.  
    project.startdate 
     
       
    • The start date of the project.  
      •  
    • Example usage: HTML
      <p>Start Date: {{ project.startdate }}</p>\n
      •  
    • You can also modify the date format      HTML
          <p>Start Date: {{project.startdate|date:\"d/m/Y\" }} </p>\n
      •  
     
    6.  
  6.  
    project.enddate 
     
       
    • The end date of the project.  
      •  
    • Example usage: HTML
      <p>End Date: {{ project.enddate }}</p>\n
      •  
    • You can also modify the date format      HTML
          <p>End Date: {{project.enddate|date:\"d/m/Y\" }} </p>\n
      •  
     
    7.  
  7.  
    project.testingtype 
     
       
    • The type of testing performed for the project (e.g., White Box, Black Box).  
      •  
    • Example usage: HTML
      <p>Testing Type: {{ project.testingtype }}</p>\n
      •  
     
    8.  
  8.  
    project.projectexception 
     
       
    • Notes or exceptions for the project, if any.  
      •  
    • Example usage: HTML
      <p>Exceptions: {{ project.projectexception|clean_html }}</p>\n
      •  
    • It uses CKeditor HTML data, using |clean_html allow to render html data securely instead of as text.
      •  
    • In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions.   HTML
      {% if project.projectexception %}\n<p>Exceptions: {{ project.projectexception|clean_html }}</p>\n{% endif %}\n
      •  
     
    9.  
  9.  
    project.owner 
     
       
    • A many-to-many relationship representing users associated as owners of the project.  
      •  
    • To display all owners: HTML
      <ul>\n  {% for owner in project.owner.all %}\n    <li>{{ owner.username }}</li>\n    <li>{{ owner.full_name }} </li>\n    <td>{{ owner.email }} </li>\n    <li>{{ owner.number }} </li>\n    <li>{{ owner.position }} </li>\n  {% endfor %}\n</ul>\n
      •  
     
    10.  
  10.  
    project.status 
     
       
    • The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).  
      •  
    • Example usage: HTML
      <p>Status: {{ project.status }}</p>\n
      •  
     
    11.  
"},{"location":"custom-report/pdf/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status. 
 
     
  • Usage Example:   You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
    •  
 HTML
<h3>Project Retests:</h3>\n  <ul>\n      {% for retest in totalretest %}\n          <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n              {% for owner in retest.owner.all %}\n                    {{ owner.full_name }}\n\n              {% endfor %}\n          </li>\n      {% endfor %}\n  </ul>\n
 
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
 HTML
{% if Report_type == 'Re-Audit' %}\n  <h3>Project Retests:</h3>\n  <ul>\n      {% for retest in totalretest %}\n          <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n            {% for owner in retest.owner.all %}\n                    {{ owner.full_name }}\n\n              {% endfor %}\n          </li>\n      {% endfor %}\n  </ul>\n{% endif %}\n
"},{"location":"custom-report/pdf/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
 
     
  • Usage Example:
    •  
 HTML
<h3>Project Scope:</h3>\n<ul>\n    {% for scope in projectscope %}\n        <li>{{ scope.scope }} - {{ scope.description }}</li>\n    {% endfor %}\n</ul>\n
"},{"location":"custom-report/pdf/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/pdf/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
     
  1.  
    vulnerability.vulnerabilityname 
     
       
    • The name of the vulnerability (e.g., \"SQL Injection\").  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n{% endfor %}\n
      •  
     
    2.  
  2.  
    vulnerability.vulnerabilityseverity 
     
       
    • The severity of the vulnerability (e.g., \"High\", \"Medium\").  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n{% endfor %}\n
      •  
     
    3.  
  3.  
    vulnerability.cvssscore 
     
       
    • The CVSS score associated with the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>CVSS Score: {{ vulnerability.cvssscore }}</p>\n{% endfor %}\n
      •  
     
    4.  
  4.  
    vulnerability.cvssvector 
     
       
    • The CVSS vector associated with the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n{% endfor %}\n
      •  
     
    5.  
  5.  
    vulnerability.status 
     
       
    • The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Status: {{ vulnerability.status }}</p>\n{% endfor %}\n
      •  
     
    6.  
  6.  
    vulnerability.vulnerabilitydescription 
     
       
    • A description of the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n{% endfor %}\n
      •  
     
    7.  
  7.  
    vulnerability.POC 
     
       
    • The proof of concept (POC) for the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n{% endfor %}\n
      •  
     
    8.  
  8.  
    vulnerability.vulnerabilitysolution 
     
       
    • The recommended solution for the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Solution: {{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n{% endfor %}\n
      •  
     
    9.  
  9.  
    vulnerability.vulnerabilityreferlnk 
     
       
    • A reference link related to the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Reference Link: {{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n{% endfor %}\n
      •  
     
    10.  
  10.  
    vulnerability.created 
     
       
    • The timestamp when the vulnerability was created.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Created: {{ vulnerability.created }}</p>\n{% endfor %}\n
      •  
     
    11.  
  11.  
    vulnerability.created_by 
     
       
    • The user who created the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Created By: {{ vulnerability.created_by.username }}</p>\n{{ vulnerability.created_by.full_name }}</p>\n{% endfor %}\n
      •  
    • Similar to project owner, you can use other filed as well  like email, number or postion etc.
      •  
     
    12.  
  12.  
    vulnerability.last_updated_by 
     
       
    • The user who last updated the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Last Updated By: {{ vulnerability.last_updated_by.username }}</p>\n{% endfor %}\n
      •  
     
    13.  
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerableinstance-model","title":"Available Variables for Vulnerableinstance Model","text":"
     
  1. instance.vulnerabilityid 
    2.  
  2. The Vulnerability object associated with the instance.  
    3.  
  3.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Vulnerability Name: {{ instance.vulnerabilityid.vulnerabilityname }}</p>\n{% endfor %}\n
     
    4.  
  4.  
    instance.project 
     
    5.  
  5. The project associated with the vulnerable instance.  
    6.  
  6.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Project: {{ instance.project.name }}</p>\n{% endfor %}\n
     
    7.  
  7.  
    instance.URL 
     
    8.  
  8. The URL of the vulnerable instance.  
    9.  
  9.  
    Example usage: HTML
    {% for instance in instances %}\n<p>URL: {{ instance.URL }}</p>\n{% endfor %}\n
     
    10.  
  10.  
    instance.Parameter 
     
    11.  
  11. The parameter of the vulnerable instance.  
    12.  
  12.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Parameter: {{ instance.Parameter }}</p>\n{% endfor %}\n
     
    13.  
  13.  
    instance.status 
     
    14.  
  14. The status of the vulnerable instance, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
    15.  
  15. Example usage: HTML
    {% for instance in instances %}\n<p>Status: {{ instance.status }}</p>\n{% endfor %}\n
    16.  
"},{"location":"custom-report/pdf/vulnerability/#displaying-vulnerable-instances-for-a-specific-vulnerability-in-a-template","title":"Displaying Vulnerable Instances for a Specific Vulnerability in a Template","text":"
The instances query set or list does not associate with the vulnerability name, instances variable contain all instances for the project, In most cases we need all instances for a vulnerability. We can do that as well, you can check in the original vulnerabilities.html in the template or you can use this: 
 
To display the instances for a specific vulnerability within a loop for vulnerabilities, you can use the following approach:
 HTML
{% for vulnerability in vuln %}\n\n <p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n\n<p>{{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n\n<p>{{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n\n  <p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n\n   <p>Status: {{ vulnerability.status }}</p>\n\n   <p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n\n   <p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n\n  {% for instance in instances %}\n\n    {% if instance.vulnerabilityid.id == vulnerability.id %}\n      <tr>\n        <td>{{ instance.URL }}</td>\n        <td>{{ instance.Parameter }}</td>\n        <td>{{ instance.status }}</td>\n      </tr>\n    {% endif %}\n\n  {% endfor %}\n\n{% endfor %}\n
"},{"location":"getting-started/Contribution/","title":"Project Contribution","text":""},{"location":"getting-started/Contribution/#project-contribution","title":"Project Contribution","text":""},{"location":"getting-started/Contribution/#creator","title":"Creator","text":"
     
  • Sourav Kalal
    •  
"},{"location":"getting-started/Contribution/#special-thanks","title":"Special Thanks","text":"
     
  •  
    DJ Scruggs A big thanks to DJ Scruggs for creating the entire ViteJS frontend from scratch and implementing the APIs for version 1.0.
     
       
    • GitHub
      •  
    • Portfolio
      •  
    • LinkedIn
      •  
     
    •  
"},{"location":"getting-started/Contribution/#mention","title":"Mention","text":"
Yonathan johnson Started creating the frontend using React. Although he could not complete the development due to certain circumstances, his initiative and effort are greatly appreciated.
"},{"location":"getting-started/Features/","title":"Features","text":""},{"location":"getting-started/Features/#features","title":"Features","text":"
     
  •  
    Automated Report Generation: APTRS automates creating comprehensive penetration testing reports, saving time and ensuring consistency.
     
    •  
  •  
    PDF Docx, and Excel Reports: Generate professional-looking PDF, Docx and Excel reports with ease, providing clients and stakeholders with clear insights into security assessments.
     
    •  
  •  
    Vulnerability Management: APTRS helps you keep track of vulnerabilities across different projects, allowing for efficient management and mitigation.
     
    •  
  •  
    User-Friendly Interface: The tool is designed with a user-friendly interface, making it accessible for both novice and experienced penetration testers.
     
    •  
  •  
    Customization: Tailor your reports to meet specific project requirements, ensuring that the generated reports align with your organization's standards.
     
    •  
  •  
    Project and Customer Management: Manage all your projects, retest, and customer all in one place. The user and project tracking allows you to monitor the user's project allocation, plans, and status.
     
    •  
"},{"location":"getting-started/Sponsors/","title":"Sponsors","text":"
     
  • Many thanks to DigitalOcean for their generous support of the project.
    •  
"},{"location":"getting-started/demo/","title":"Demo","text":""},{"location":"getting-started/demo/#live-demo-instance","title":"Live Demo Instance","text":"
Explore the features of APTRS through our live demo instance:
 
     
  • Live Demo
    •  
  • Username: sourav.kalal@aptrs.com
    •  
  • Password: I-am-Weak-Password-Please-Change-Me
    •  
 
Feel free to interact with the tool and see how APTRS can streamline your penetration testing workflows.
 
\ud83c\udf28\ufe0f Huge thanks to DigitalOcean for their support of the APTRS project.
 
Warning
 
\ud83d\udea7 APIs related to user profiles and user management, such as adding, editing, deleting users, and changing passwords, are disabled on the cloud-hosted demo instance.
"},{"location":"getting-started/license/","title":"License","text":"
The APTRS project is released under the MIT License, which is a permissive open-source license allowing anyone to use, modify, and distribute the software freely. This license ensures that the software remains open and accessible while permitting both personal and commercial use, provided that the original copyright notice and license terms are included in all copies or substantial portions of the software
"},{"location":"installation/certificate/","title":"Secure Certificate","text":"
APTRS uses HTTPS with a self-signed certificate. If you would like to replace the self-signed certificate with your own, you can do so by updating the certificate and key files located at:
 
https://github.com/APTRS/APTRS/tree/main/Certificate
"},{"location":"installation/docker/","title":"Docker","text":""},{"location":"installation/docker/#linux","title":"Linux","text":"Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncp env.docker .env\nnano .env\ndocker-compose up \n
"},{"location":"installation/docker/#windows","title":"Windows","text":"Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncopy env.docker .env\nnotepad .env\ndocker-compose up \n
 
Note
 
The .env file contains all the environment variables, such as passwords for JWT, Database credentials, Cloud S3 bucket details, etc. It\u2019s important to update the default passwords and details before deploying the application. For more information, refer to the Environment Variables section.
"},{"location":"installation/env/","title":"Environment Variables","text":"
The APTRS backend uses the .env file to store credentials such as S3 bucket information, database credentials, secret keys, whitelisted IPs/domains, and more.
 
     
  • If you are deploying the application with Docker, make sure to update the details in the .env file from the project root.
    •  
  • If you are deploying the application without Docker, you will need to update specific details like the S3 bucket and whitelisted IPs.
    •  
 ENV Description Docker Linux Server Manual Setup SECRET_KEY This key is used by Backend including JWT, Should be secured and random. Manually need to be updated in env file Manually need to be updated in env file WHITELIST_IP This allows to set whitelisted IP/domain with port number to allow loading resource during PDF report to prevent SSRF vulnerability. Manually need to be updated in env file, make sure to keep the https://nginx as its required to connect with nginx within Docker Manually need to be updated in env file based on your domain name, IP etc. ALLOWED_HOST Whitelist allowed host to prevent host header injection attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. CORS_ORIGIN Whitelist allowed origin to prevent cross origin attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. REDIS_URL Redis Server Details including IP, Port and password Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Do not update other details except password Manually need to be updated in env file for REDIS password, IP and Port details REDIS_PASSWORD Redis Server password for Redis image in docker Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Password in REDIS_URL  and REDIS_PASSWORD should be same Not needed and no need to update/add. POSTGRES_USER , POSTGRES_PASSWORD, POSTGRES_PORT, POSTGRES_DB Postgres DB username, password, port, and DB names Manually need to be updated in env file Manually need to be updated in env file. POSTGRES_HOST Postgres host name Should not be updated. Manually need to be updated in env file. USE_S3 If you want to use Cloud S3 bucket Digital Ocean or AWS s3 bucket. Default False, you can change it to True Optional Optional AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_STORAGE_BUCKET_NAME AWS_S3_REGION_NAME AWS_S3_CUSTOM_DOMAIN AWS_S3_ENDPOINT_URL Bucket details if USE_S3 is set to True Optional Optional USE_DOCKER Used by APTRS Django code to validate if application deployed on Docker or Not Optional, It is already declared as True in Docker file Required to set to False USER_TIME_ZONE Used by APTRS Django code and Background task schedule time using celery Required to set the local time zon or UTC Required to set the local time zon or UTC 
     
  • List of Supported Time Zone
    •  
"},{"location":"installation/frontend/","title":"Frontend","text":"
APTRS now includes the source code of the Vite.js frontend by default, instead of a pre-built version. This change allows you greater flexibility to customize the frontend as needed. If you are deploying the application using Docker, the build process is handled automatically, so you don't need to worry about creating a production build manually.
 
However, if you choose to manually deploy APTRS, you will need to manually build the production version of the frontend and serve it using Nginx or any other reverse proxy.
 
To build the production version from the Vite.js source code, follow these steps:
 Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncd Frontend\ncp env.example .env\nnpm run build\n
 
Note
 
The .env file contains settings like the backend API domain and app environment. You can modify these as needed.
 
By default, APTRS serves both the backend and frontend on the same server, meaning they share the same IP/domain and port. The .env file uses just /api/ in docker build for the backend API domain. This setup is recommended to avoid issues with image uploads in the CKEditor within APTRS and to prevent conflicts related to Same-Origin policies.
"},{"location":"installation/frontend/#hosting-the-frontend-and-api-together","title":"Hosting the Frontend and API Together","text":"
If you wish to host the frontend on a separate domain, IP, or port from the backend API, you can configure the backend API's domain in the .env file within the Frontend folder. For example:
 Bash
nano .env\n\nVITE_APP_API_URL = http://backend-api.com/api/\nnpm run build\n
 
However, it is not recommended to host the API and frontend on separate domains, IPs, or ports. Here's why:
 
     
  1.  
    JWT Token Authentication and Cookies:
     
       
    • The API uses a combination of JWT tokens in headers and cookies for authentication and access control.
      •  
    • Cookies are domain-specific and cannot be shared across different domains unless explicitly configured with a domain-wide scope. This can lead to complexities in maintaining secure cross-domain authentication.
      •  
     
    2.  
  2.  
    Static Image Loading Issues:
     
       
    • Browsers do not allow custom headers, such as JWT tokens, for loading static resources like images.
      •  
    • APTRS addresses this by using cookies for authentication, allowing images protected by the API to be loaded by authenticated users. However, this setup is difficult to manage across separate domains, as it relies on cookies being available in the same domain scope.
      •  
     
    3.  
  3.  
    Unified Image Path Management:
     
       
    • APTRS supports storing images locally or on S3. Using the API for image access ensures consistency, as images are accessed through the same API endpoint regardless of their storage location.
      •  
    • This approach prevents exposing hardcoded S3 bucket URLs in CKEditor or frontend code. Additionally, if the S3 bucket URL changes or signed URLs expire, the API path remains consistent.
      •  
     
    4.  
  4.  
    Image Management with CKEditor:
     
       
    • APTRS manages images uploaded through CKEditor by serving them directly via the backend API, rather than using a web server. This design ensures that sensitive images, such as those used for proofs of concept (POCs), are accessible only to authenticated users. These images are protected by authentication tokens and are not publicly exposed.
      •  
    •  
      CKEditor uses <img> tags with a src attribute pointing to the API's image path. For example:
       HTML
      <img src=\"https://api.yourdomain.com/api/path/to/image.jpg\" />\n
       
      •  
     
    5.  
"},{"location":"installation/frontend/#challenges-with-hosting-the-api-and-frontend-on-separate-domains","title":"Challenges with Hosting the API and Frontend on Separate Domains","text":"
When the API is hosted on a separate domain from the frontend:
 
     
  • CKEditor hardcodes the API domain in the src attribute of the images.
    •  
  • If the API domain name, IP, or port changes, previously uploaded images will fail to load, as CKEditor cannot dynamically update the src attribute.
    •  
  • Additionally, browsers loading static resources like images do not support custom headers (e.g., JWT tokens), which can complicate access control for images requiring authentication.
    •  
"},{"location":"installation/frontend/#benefits-of-hosting-api-and-frontend-on-the-same-domain","title":"Benefits of Hosting API and Frontend on the Same Domain","text":"
If both the API and frontend are hosted on the same domain, the frontend can be built with VITE_API_URL=/api/. This approach allows CKEditor to generate image paths relative to the frontend's base domain, such as:
 HTML
     <img src=\"/api/path/to/image.jpg\" />\n
 
This configuration provides several advantages:
 
     
  • Domain Independence: The image path (/api/path/to/image.jpg) remains valid even if the domain name, IP address, or port changes, as long as the API and frontend share the same base domain.
    •  
  • Simplified Image Access: The relative path ensures that images are seamlessly accessible without hardcoding the API domain, reducing the risk of broken links if deployment configurations change.
    •  
  • Consistent User Experience: End users can load images securely without encountering authentication or cross-domain issues.
    •  
"},{"location":"installation/frontend/#recommendation","title":"Recommendation","text":"
For best results:
 
     
  1.  
    Host Both API and Frontend on the Same Domain
     
       
    • Use a reverse proxy, such as Nginx, to host both the API and frontend on the same domain.
      •  
    • Configure the frontend to use VITE_API_URL=/api/.
      •  
     
    This setup improves maintainability and ensures robustness against deployment changes, as the relative paths remain valid even if the domain name, IP, or port changes.
     
    2.  
  2.  
    Deploying Frontend and Backend on Separate Servers
     
       
    •  
      If you require separate servers for the frontend and backend (e.g., for scalability, load balancing, or easier maintenance), you can still serve both on the same domain or IP and port for users by using a reverse proxy.
       
      •  
    •  
      For example, you can deploy the frontend on one server and the backend on another, but configure your reverse proxy to route requests based on the path:
       
         
      • Requests to /api/*, media/*, static/* are proxied to the backend server.
        •  
      • Other requests (e.g., for the frontend) are served by the frontend server.
        •  
       
      •  
     
    3.  
"},{"location":"installation/install/","title":"Install","text":"
APTRS can be installed using two methods:
 
     
  • Docker (Recommended for most users)
    •  
  • Manual (User with Knowledge of Nginx and Little Python and Nodejs)
    •  
 
Note
 
APTRS does not natively support Windows installations and setting it up on Windows is not recommended. While it's possible to manually install certain components (such as the APTRS Backend, Frontend, and Database) on Windows, key dependencies like Redis require a Linux environment. Instead, you can use the Docker setup for Windows, which is the preferred option for Windows users.
 
Note
 
Default creds are sourav.kalal@aptrs.com & I-am-Weak-Password-Please-Change-Me
 
Note
 
APTRS uses cookie attributes such as Secure, HttpOnly, and Lax. For users with a Docker setup, these attributes will not have any effect. However, users with a manual setup need to ensure that they use HTTPS and that both the front end and back end are on the same domain or IP address.
"},{"location":"installation/manual/","title":"Manual Installation","text":"
If you prefer to install the APTRS without Docker and have more control over each service, such as Redis, Postgresql, Nginx, etc., or if you want to host the database on a different server, Redis on a different server, etc., you can follow the below process for deploying the APTRS on a server without Docker. 
 
The steps mentioned below were tested on the below setup:
 
     
  • OS - Ubuntu 24.10
    •  
  • Python - 3.12.7 \u00a0(3.9+ is required)
    •  
  • Python Poetry - 1.8.4
    •  
  • PostgreSQL - 16.4 (Ubuntu 16.4-1build1)
    •  
  • Redis Server - 7.0.15
    •  
  • Nginx - 1.26.0
    •  
  • NodeJS - 20.16.0 (18+ is required)
    •  
  • NPM - 9.2.0
    •  
 
Note
 
While we have provided detailed steps for manual installation and deployment, please note that this method is more prone to errors. Variations in software versions, updates, system configurations, and other factors may result in unexpected issues. Manual installation is intended for individuals who have a solid understanding of Linux, some level of development experience, or expertise in application deployment, and are comfortable troubleshooting potential errors that may arise.
"},{"location":"installation/manual/#reference-links","title":"Reference Links","text":"
     
  • Digital Ocean - How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu
    •  
  • Digital Ocean - How To Install Nginx on Ubuntu 20.04
    •  
  • Digital Ocean - How To Secure Nginx with Let's Encrypt on Ubuntu 20.04
    •  
  • Digital Ocean - How To Install and Secure Redis on Ubuntu 22.04
    •  
  • Digital Ocean - How To Install and Use PostgreSQL on Ubuntu 20.04
    •  
"},{"location":"installation/manual/#postgresql-setup","title":"PostgreSQL Setup","text":"
Run the below command to install PostgreSQL.
 Bash
sudo apt-get install \u00a0postgresql postgresql-contrib\n
 
After the installation is complete, we can access the PostgreSQL shell using the command below.
 Bash
sudo -u postgres psql\n
 
From the PostgreSQL shell, create a new database for the APTRS project. Change the name to something relevant to the project.
 Bash
CREATE DATABASE aptrsdb;\n
 
Next, create a database user for our project. Make sure to select a secure password:
 Bash
CREATE USER aptrsdb_user WITH PASSWORD 's!!D%AriPB-MO~5';\n
 
We will set the default encoding to UTF-8 and adjust other settings. Please update the time zone according to your preference, and ensure we use the same time zone as the APTRS.
 Bash
ALTER ROLE aptrsdb_user SET client_encoding TO 'utf8';\nALTER ROLE aptrsdb_user SET default_transaction_isolation TO 'read committed';\nALTER ROLE aptrsdb_user SET timezone TO 'UTC';\n\n\\c aptrsdb;\nGRANT USAGE ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO aptrsdb_user;\nALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON DATABASE aptrsdb TO aptrsdb_user;\n\\q\n
 
After completing our tasks, we ensure that the PostgreSQL service is running and set to start automatically on reboot.
 Bash
sudo systemctl start postgresql\nsudo systemctl enable postgresql\n
"},{"location":"installation/manual/#redis-setup","title":"Redis Setup","text":"
To install Redis, run the command below.
 Bash
sudo apt install redis-server\n
 
After installing Redis, we should ensure to change the supervised setting and add a password to our Redis service.
 
Bash
sudo nano /etc/redis/redis.conf\n
 \u00a0 In the redis.conf file, add the following content. Ensure to update the password to a new, secure password.
 Bash
supervised systemd\nrequirepass s!!D%AriPB-MO~5\n
 
After completing our tasks, we ensure that the Redis service is running and is set to start automatically on reboot.
 Bash
sudo systemctl restart redis\nsudo systemctl enable redis\nsudo systemctl restart redis.service\n
"},{"location":"installation/manual/#aptrs-django-apis-setup","title":"APTRS Django APIs Setup","text":"
Run the below command to install Python and other requirements for the APTRS.
 Bash
sudo apt install python3-venv python3-dev libpq-dev weasyprint\n
 
It's better to separate the API and web service from other users on the machine. It's advisable to create a separate account for it.
 Bash
sudo adduser aptrs\nsudo usermod -aG sudo aptrs\nusermod -a -G www-data aptrs\nsudo chown -R aptrs:www-data /home/aptrs\nsudo su - aptrs\n
 
APTRS uses Python Poetry to manage dependencies, so we ensure its installation.
 Bash
curl -sSL https://install.python-poetry.org | python3 -\n
 
By default, Poetry is not added to the user or system environment. Ensure you add it to the environment.
 Bash
export PATH=\"/home/aptrs/.local/bin:$PATH\"\n
 
Once completed, we can download the APTRS from GitHub, install the dependencies, and copy the example .env file.
 
Bash
cd /home/aptrs\ngit clone https://github.com/APTRS/APTRS\ncd APTRS\npoetry install\ncd APTRS\ncp cd APTRS .env \u00a0# The .env file should be located in the same directory as the manage.py file.\n
 After obtaining the .env file from the demo environment file, ensure that you update it with the following details: the password for Redis, the PostgreSQL hostname or IP address, the Redis hostname or IP address, the secret key, and any other necessary information. It's important to review all the details in the .env file carefully. For more information on configuring the .env file and the various data it contains, please refer to the Environment Variables section.
 
Few Important details for .env file:
 
     
  •  
    WHITELIST_IP: Add the server domain name if you're using one; if using a public IP, include that as well. For local network access, add the server's internal IP to the whitelist. Specify the protocol (HTTP or HTTPS) and use Nginx instead of the Django default port (8000). You don\u2019t need to specify a port if using HTTP on 80 or HTTPS on 443. If using S3 buckets, include the bucket URL.
     
    •  
  •  
    CORS_ORIGIN: Since the frontend and backend will be on the same server, simply allow the server's public or local IP, along with the appropriate protocol and port, if necessary. Both frontend and backend should be accessible via the same domain or IP using Nginx reverse proxy. For more details, check the Frontend documentation.
     
    •  
  •  
    ALLOWED_HOST: Set this only for the server's domain name or public/internal IP, based on how APTRS will be accessed.
     
    •  
  •  
    SECRET_KEY: Make sure to update it with a secure key; the same key will be used to generate a JWT token.
     
    •  
 
From the directory where manage.py is located, run the command below.
 Bash
poetry shell\npython3 manage.py makemigrations accounts\npython3 manage.py makemigrations configapi\npython3 manage.py makemigrations customers\npython3 manage.py makemigrations project\npython3 manage.py makemigrations vulnerability\npython3 manage.py makemigrations\npython3 manage.py migrate\npython3 manage.py first_setup\nexit\n
 
Once we have completed the required setup, we need to start the server. APTRS uses Gunicorn for this purpose, which should already be installed through the steps we have completed so far. Since we are using Poetry, we need to locate the full path of Gunicorn for the APTRS project using the command below:
 Bash
$> cd /home/aptrs/APTRS\n$> poetry run which gunicorn\n\n##We might get the full path like below, this will be different for all users\n/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn\n
 
Once we have the full path for gunicorn, we can set up the gunicorn.service with the command below:
 Bash
sudo nano /etc/systemd/system/gunicorn.service\n
 
In the nano file editor, paste the following text. Ensure to update the full path for gunicorn in the gunicorn.service file.
 Bash
[Unit]\nDescription=gunicorn daemon to serve APTRS\nRequires=gunicorn.socket\nAfter=network.target\n\n[Service]\nUser=aptrs\nGroup=www-data\nWorkingDirectory=/home/aptrs/APTRS/APTRS\nExecStart=/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn --workers 3 --access-logfile - --bind unix:/run/gunicorn.sock APTRS.wsgi:application\n\n[Install]\nWantedBy=multi-user.target\n
 
We can now set up the gunicorn.socket using the command below:
 Bash
sudo nano /etc/systemd/system/gunicorn.socket\n
 Bash
[Unit]\nDescription=gunicorn socket\n\n[Socket]\nListenStream=/run/gunicorn.sock\n\n[Install]\nWantedBy=sockets.target\n
 
Now that everything is ready, we can start the Gunicorn service using the command below.
 Bash
sudo systemctl start gunicorn.socket\nsudo systemctl enable gunicorn.socket\nsudo systemctl enable gunicorn\nsudo systemctl daemon-reload\nsudo systemctl restart gunicorn\n
 
You can verify whether the APTRS APIs are operational by using the command below.
 Bash
curl --unix-socket /run/gunicorn.sock localhost/api/config/ping/\n\n{\"status\":\"ok\",\"message\":\"Server is up and running!\"}\n
 
In case of an error, you can check if the socket and service have any issues using the command below. Bash
sudo systemctl status gunicorn.socket\nsudo systemctl status gunicorn\n
"},{"location":"installation/manual/#frontend-vitejs-setup","title":"Frontend ViteJs Setup","text":"
To install Node.js, run the command below.
 Bash
sudo apt install nodejs\nsudo apt install npm\n
 
After installing NPM and Node.js, we need to create a .env file for the front end. This .env file will contain the URL for the backend Django API. Since we plan to deploy both the API and the frontend on the same server and they will be accessible through the same domain or IP address using Nginx, we will specify the backend URL as /api/. For more details, please refer to the Frontend documentation.
 Bash
cd /home/aptrs/APTRS/frontend\ncp env.example .env\nnano .env\n
 
In the Nano editor, modify the content to reflect the following changes:
 Bash
VITE_APP_API_URL = /api/\nVITE_APP_ENV = production\n
 
Now that we have configured the env file, we can install the required packages for the frontend with the command below:
 Bash
npm install\n
 
Once we have all the packages installed, we can build the frontend using the command below.
 Bash
npm run build\n
 
Once the build is completed, we can see all the front-end build at the directory below:
 Bash
cd /home/aptrs/APTRS/frontend/dist\nls \n\nandroid-chrome-192x192.png \u00a0assets \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 favicon.ico \u00a0 \u00a0 \u00a0 logo.svg \u00a0 \u00a0 \u00a0 stats.html\nandroid-chrome-512x512.png \u00a0favicon-16x16.png \u00a0hero-desktop.png \u00a0manifest.json\napple-touch-icon.png \u00a0 \u00a0 \u00a0 \u00a0favicon-32x32.png \u00a0index.html \u00a0 \u00a0 \u00a0 \u00a0robots.txt\n
"},{"location":"installation/manual/#nginx-setup","title":"Nginx Setup","text":"
We have everything set up, and our APIs are running with Gunicorn. Now, we need to configure the frontend to serve static files with Nginx and connect Gunicorn to Nginx. To get started, we first need to install Nginx using the command below:
 Bash
sudo apt install nginx\n
 
To complete the setup, we can assume the domain name for our web server is demo.aptrs.com. The configuration below will have the nginx configuration files or folder names based on the domain, which users should replace with their actual domain.
 
Next, we will create a new server block in the Nginx sites-available directory using the following command:
 Bash
sudo nano /etc/nginx/sites-available/demo.aptrs.com\n
 
Paste the Below nginx configuration,
 Bash
# HTTP server configuration\nserver {\n\u00a0 \u00a0 listen 80;\n\u00a0 \u00a0 server_name demo.aptrs.com; \u00a0# Replace with your domain\n\n\u00a0 \u00a0 server_tokens off;\n\u00a0 \u00a0 client_max_body_size 100M;\n\n\n\n\u00a0 \u00a0 ### Host Validation - > Update according to your need\n\u00a0 \u00a0 if ( $host !~* ^(demo.aptrs.com)$ ) {\n\u00a0 \u00a0 \u00a0 \u00a0 return 444;\n }\n\n\u00a0 \u00a0 # Pass all /api/* to the Django backend \n\u00a0 \u00a0 location /api/ {\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_pass http://unix:/run/gunicorn.sock;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header X-Forwarded-Proto $scheme;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header Host $host;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_redirect off;\n }\n\n\u00a0 \u00a0 # Home page for frontend\n\u00a0 \u00a0 location / {\n\u00a0 \u00a0 root /home/aptrs/APTRS/frontend/dist;\n\u00a0 \u00a0 index index.html index.htm;\n\u00a0 \u00a0 try_files $uri $uri/ /index.html =404;\n }\n\u00a0 \u00a0 ## Server Static from Django over nginx\n\u00a0 \u00a0 location /static/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/static/; \n }\n\n\u00a0 \u00a0 # Blocked, accessing the whole media folder may lead to access to sensitive images like POC images, \n\u00a0 \u00a0 #location /media/ {\n\u00a0 \u00a0 # \u00a0 \u00a0alias /home/aptrs/APTRS/APTRS/media/; \u00a0# Path to your media files\n\u00a0 \u00a0 #} \n\n\u00a0 \u00a0 location = /favicon.ico { \n\u00a0 \u00a0 alias /home/aptrs/APTRS/frontend/dist/favicon.ico;\n\u00a0 \u00a0 access_log off; \n\u00a0 \u00a0 log_not_found off; \n\u00a0 \u00a0 \n }\n\n\u00a0 \u00a0 ## Server user profile photo\n\u00a0 \u00a0 location /media/profile/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/profile/; \u00a0# Path to your media files\n } \n\n\u00a0 \u00a0 ## Server Company Logo Images\n\u00a0 \u00a0 location /media/company/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/company/; \u00a0# Path to your media files\n }\n\n\u00a0 \u00a0 ## HTML Report design Images like background images\n\u00a0 \u00a0 location /media/report/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/report/; \u00a0# Path to your media files\n } \n\n\u00a0 \u00a0 access_log /var/log/nginx/APTRS_access.log; \u00a0# Path to access log file\n\u00a0 \u00a0 error_log /var/log/nginx/APTRS_error.log; \u00a0 # Path to the error log file\n}\n
 
Let\u2019s enable the file by creating a link from it to the\u00a0sites-enabled\u00a0directory, which Nginx reads from during startup:
 Bash
sudo ln -s /etc/nginx/sites-available/demo.aptrs.com /etc/nginx/sites-enabled/\n
 
Let's verify if any error from the nginx with
 
Bash
sudo nginx -t\n
 If there are no errors we can start the nginx
 Bash
sudo systemctl restart nginx\n
"},{"location":"installation/manual/#https-certificate","title":"HTTPS Certificate","text":"
Once we have the domain name we can get the CA certificate with certbot using the below command. 
 Bash
sudo apt install certbot python3-certbot-nginx\nsudo certbot --nginx -d demo.aptrs.com\nsudo systemctl status certbot.timer\nsudo certbot renew --dry-run\n
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Automated Penetration Testing Reporting System","text":"
APTRS (Automated Penetration Testing Reporting System) is a Python, Django and ViteJS-based automated reporting tool designed for penetration testers and security organizations. This tool streamlines the report generation process by enabling users to create PDF, Docx and Excel reports directly, eliminating the need for manual approaches. Additionally, APTRS offers a systematic way to monitor and manage vulnerabilities within various projects. Keep your penetration testing projects organized and efficient with APTRS.
"},{"location":"API/","title":"API Documentation","text":"
     
  • Postman APIs
    •  
  • Postman API Collection
    •  
  • Swagger
    •  
"},{"location":"Features/","title":"Index","text":"
APTRS offers various features and configurations, including the management of companies, customers, projects, retests, different types of reports, configurations, templates, and more. The Features Documentation provides detailed information on the different setups, features, and use cases.
"},{"location":"Features/Users/users/","title":"User Management in APTRS","text":"
APTRS provides robust user management capabilities, allowing you to add, edit, and delete users. Each user can log in to the APTRS platform using their credentials, and they have the option to set a profile photo through the Edit Profile feature. In version 1.0, users are also able to change their passwords.
 
"},{"location":"Features/Users/users/#user-types","title":"User Types","text":"
There are two types of users in APTRS:
 
     
  1. Admin Users: Admin users have elevated permissions and can perform administrative tasks, including managing user accounts and configurations.
    2.  
  2. Non-Admin Users: Non-admin users have restricted access and can perform tasks based on the permissions and groups assigned to them.
    3.  
 
All users can log in and perform tasks according to their assigned permissions and groups. 
 
Info
 
For detailed information on permissions and groups, please refer to the Permissions and Groups section.
"},{"location":"Features/Users/users/#user-classification","title":"User Classification","text":"
Users are classified into two categories:
 
     
  1. Internal Users (Staff Users): By default, all users added to the system are marked as staff users, indicating they are internal users of the APTRS.
    2.  
  2. External Users (Non-Staff Users): External users are designated as non-staff users. For details on managing non-staff users, please refer to the Customer section.
    3.  
 
This structured approach to user management ensures that you can effectively manage access levels and user capabilities within the APTRS platform.
"},{"location":"Features/Users/users/#important-note-on-deleting-users","title":"Important Note on Deleting Users","text":"
All projects in APTRS must have an owner. Deleting a user will cause errors, as projects assigned to that user will no longer have an owner. If you need to disable a user\u2019s account, it is recommended to set the account to \"inactive\" rather than deleting it. If you choose to delete the user, be aware that you will need to manually reassign ownership of all the projects associated with that user to avoid issues.
"},{"location":"Features/company/company/","title":"Company Management in APTRS","text":"
APTRS allows you to add and manage companies, with two types of companies supported: Internal Companies and External (Non-Internal) Companies.
 
"},{"location":"Features/company/company/#internal-companies","title":"Internal Companies","text":"
APTRS assumes that your company, the one deploying and using APTRS, is the internal company. When you deploy APTRS for the first time, an internal company is automatically created. This company is assigned to you and cannot be deleted or replaced. However, you can rename it to reflect your actual company name.
 
Key details about internal companies:
 
     
  • Internal Company Setup: The internal company is auto-created during the initial setup, and no additional internal companies can be added afterward.
    •  
  • User Assignment: All users added through the User Management page will automatically be part of the internal company.
    •  
  • Reports: Users and data from the internal company will be reflected in your reports as staff or internal users.
    •  
"},{"location":"Features/company/company/#external-non-internal-companies","title":"External (Non-Internal) Companies","text":"
All companies manually added after the initial setup are classified as External Companies. These are typically client companies or third-party organizations.
 
Key details about external companies:
 
     
  • User Management: You cannot add users to external companies through the User Management page. Any user added through this page will be assigned as a staff member of the internal company.
    •  
  • Assigning Users to External Companies: To assign users to external companies, you need to go through the Customer section, which manages external users.
    •  
  • Projects: You can create projects for both internal and external companies, allowing you to track and manage work for client companies separately from your own.
    •  
 
This setup ensures a clear distinction between your internal users and external client companies, making it easier to manage access, projects, and reports within APTRS.
 
Warning
 
Deleting a company will also delete all associated users. Make sure to reassign or handle any users before deleting a company.
"},{"location":"Features/company/customer/","title":"Customer Management in APTRS","text":"
Customers in APTRS are external users who belong to external (non-internal) companies. You can manage these users from the Customer page, where external users are added and tracked, and they are included in reports as customer users.
 
"},{"location":"Features/company/customer/#adding-customers","title":"Adding Customers","text":"
When adding a customer, you will need to provide the following information:
 
     
  • Email: The customer's email address.
    •  
  • Company: The external company they belong to.
    •  
  • Password: A password is required as part of the future functionality.
    •  
 
Though passwords are required during customer creation, as of version 1.0, external users do not yet have access to login, API, or dashboard features. These features are planned for future releases, where customers will be able to log into the APTRS dashboard, view ongoing and past projects, download reports, and more.
 
This allows APTRS to lay the groundwork for future functionality while managing customer data and ensuring they are accurately represented in reports.
"},{"location":"Features/configuration/configuration/","title":"Configuration","text":"
The Configuration section allows admin users or users with the Manage Configurations permission to add and manage various settings. In APTRS, users can define Project Types, such as \"Mobile Application Testing,\" which are used when creating projects and are also referenced in PDF and DOCX reports. Multiple project types can be added to suit different testing needs.
 
In addition to project types, users can also create Report Standards. When generating a report, users are required to select the applicable testing standard, such as OWASP for web application testing. Users can add additional standards here, which can then be used in the generated reports.
 
"},{"location":"Features/dashboard/dashboard/","title":"Dashboard","text":"
The Dashboard provides a personalized view of projects based on the logged-in user\u2019s ownership and project status. Unlike the Projects View Page, which lists all projects within APTRS, the Dashboard only displays projects where the logged-in user is the owner and the project is not marked as completed. The Dashboard shows projects with the following statuses: Delay, In Progress, or Upcoming, as long as the user is the owner of those projects.
 
In addition to active or upcoming projects, the Dashboard also displays completed projects if the project has an active retest. Even if a project is marked as completed, it will be shown in the Dashboard if it has any upcoming, in-progress, or delayed retests where the logged-in user is the owner of the retest task.
 
This also applies in cases where the user is the owner of the retest task for a completed project, even if the user is not the owner of the original project. In such cases, the project will still appear on the Dashboard, allowing the user to view and manage their active retest tasks.
 
"},{"location":"Features/permission/permission/","title":"Groups and Permissions in APTRS","text":"
APTRS uses permissions to control access to certain APIs and restrict features to specific users. To streamline this process, APTRS allows you to create groups and assign permissions to those groups. Once a group is created, you can assign users to one or more groups. A user assigned to multiple groups will inherit all the permissions from those groups.
 
"},{"location":"Features/permission/permission/#how-permissions-work","title":"How Permissions Work","text":"
Permissions are pre-defined within APTRS to regulate access to various functionalities. These permissions cannot be modified or created from the user interface, as they are hard-coded in the backend. However, you can create custom groups and assign these predefined permissions to the groups. When users are assigned to a group, they will automatically gain all the permissions associated with that group.
"},{"location":"Features/permission/permission/#admin-users-and-permissions","title":"Admin Users and Permissions","text":"
Admin users in APTRS are not restricted by permissions or group assignments. This means that even if an admin user has no group assigned or is assigned to a group with limited permissions, they will still have full access to all features and APIs in the system. Admin users are always granted full control, regardless of group membership or assigned permissions.
"},{"location":"Features/permission/permission/#default-groups","title":"Default Groups","text":"
When you first deploy APTRS, several default groups are created with specific permissions. The most important groups are Project Manager and Manager. These groups are crucial for report generation, as they are used to add project manager and manager details to reports.
 
While you can edit the permissions assigned to these groups, it is important to retain the group names (\"Project Manager\" and \"Manager\") if you want APTRS to correctly include project manager and manager details in the reports. Removing or renaming these groups may cause issues with report generation and prevent the correct user details from being added to reports.
"},{"location":"Features/permission/permission/#list-of-permissions-as-of-version-10","title":"List of Permissions (as of version 1.0)","text":"
     
  •  
    Manage Users: Users with this permission can add, edit, and delete users, manage groups, and assign permissions to groups. They can also create and delete groups.
     
    •  
  •  
    Manage Projects: Users with this permission can create, edit, and delete projects. They can add vulnerabilities or retests within a project, generate reports, and add scope to projects. By default, users cannot select project or retest owners; projects and retests created by users with this permission will automatically mark the creator as the owner.
     
    •  
  •  
    Assign Projects: This permission allows users to select and assign project or retest owners. Users with this permission can assign any user as the owner of a project or retest.
     
    •  
  •  
    Manage Vulnerability Data: Users with this permission can add, edit, and delete entries in the vulnerability database or templates.
     
    •  
  •  
    Manage Customers: Users with this permission can add, edit, and delete customers.
     
    •  
  •  
    Manage Companies: Users with this permission can add, edit, and delete companies.
     
    •  
  •  
    Manage Configurations: Users with this permission can manage various application configurations.
     
    •  
"},{"location":"Features/project/Vulnerability/","title":"Project Vulnerability","text":"
Each project can have associated vulnerabilities. You can navigate to the Vulnerability tab within a project to manage its vulnerabilities. This tab allows you to add, edit, or remove vulnerabilities specific to that project, providing a dedicated space to document identified security issues, their descriptions, solutions, CVSS scores, and other relevant details.
 
Using the Vulnerability Database, you can quickly import common vulnerabilities with pre-filled information, saving time when adding recurring or well-documented issues across multiple projects.
 
"},{"location":"Features/project/Vulnerability/#adding-vulnerabilities","title":"Adding Vulnerabilities","text":"
APTRS provides multiple ways to add vulnerabilities to a project, offering flexibility in how you manage and document security issues.
 
     
  •  
    Search and Add: This feature allows you to search for vulnerabilities by title or name from the Vulnerability DB or Template. Once you select a vulnerability from the search results, a new entry is created within the project, automatically populated with the title, description, solution, reference link, and CVSS score from the Vulnerability DB. This approach allows for efficient reuse of information with pre-filled details, saving time on repetitive entries.
     
    •  
  •  
    Add New: Selecting \"Add New\" will create a blank vulnerability entry within the project. All fields are initially empty except for the title, which is set to \"New Vulnerability.\" This option is ideal if you need to manually document unique vulnerabilities not in the database. You can fill in all required details such as description, solution, and severity.
     
    •  
  •  
    Upload CSV: This option is designed specifically for importing vulnerabilities from Nessus scan outputs. You can upload a Nessus vulnerability scan CSV report, which APTRS will parse to extract details such as URL or IP, port, title, description, and more. Parsed vulnerabilities are then added directly to the project, saving time on data entry for larger assessments.
     
    •  
"},{"location":"Features/project/Vulnerability/#nessus-csv","title":"Nessus CSV","text":"
This feature can also be used for other, non-Nessus scan reports. As long as the CSV file contains the required columns with matching names, APTRS will process it just like a Nessus report, making it a versatile option for importing vulnerabilities from various sources.
"},{"location":"Features/project/Vulnerability/#required-csv-columns","title":"Required CSV Columns","text":"
To ensure that vulnerabilities are parsed correctly, your CSV file should include the following columns:
 
     
  • Host: The IP address or URL of the affected system.
    •  
  • Port: The network port where the vulnerability was found.
    •  
  • Name: The title of the vulnerability, providing a brief identifier.
    •  
  • Description: A detailed explanation of the vulnerability, including its nature and potential impact.
    •  
  • Solution: Recommended actions or patches to mitigate or resolve the vulnerability.
    •  
  • Risk: The severity level of the vulnerability (e.g., Info, Low, Medium, High, Critical). APTRS uses this to assign a default CVSS score and vector.
    •  
"},{"location":"Features/project/Vulnerability/#cvss-score-and-vector","title":"CVSS Score and Vector","text":"
As of version 1.0, APTRS does not accept CVSS scores and vectors from CSV imports because default Nessus reports do not include them. Instead, APTRS assigns a default CVSS score and vector based on the Risk level provided in the CSV file.
"},{"location":"Features/project/Vulnerability/#default-cvss-scores-and-vectors-cvss-31","title":"Default CVSS Scores and Vectors (CVSS 3.1)","text":"
These default values are automatically assigned based on the risk level when the CSV is parsed:
 Severity Base Score Vector Critical 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H High 7.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L Medium 5.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L Low 3.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N Informational 0.0 CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N 
These defaults ensure consistency in reporting for imported vulnerabilities, even if specific CVSS details aren\u2019t included in the CSV file.
"},{"location":"Features/project/Vulnerability/#vulnerability-instances","title":"Vulnerability Instances","text":"
Each vulnerability in a project is required to have an instance. An instance represents the specific URL, parameter, IP address, and port number of the affected vulnerability. Each instance within a vulnerability can have its own status, allowing for more granular tracking and resolution.
 
"},{"location":"Features/project/Vulnerability/#vulnerability-and-instance-status","title":"Vulnerability and Instance Status","text":"
The status of each vulnerability and its instances is tracked individually to provide clear insights into the resolution progress. Below are the details on how the status is managed and calculated for both vulnerabilities and their instances.
 
The status of a vulnerability and its instances are interconnected. There are three possible statuses for both vulnerabilities and instances:
 
     
  • Vulnerable: The vulnerability or instance has unresolved security issues.
    •  
  • Confirmed Fix: The vulnerability or instance has been resolved and no longer has security issues.
    •  
  • Accepted Risk: The vulnerability or instance remains unresolved, but the customer or client has accepted the associated risk.
    •  
 
These statuses function as follows:
 
     
  1.  
    Changing Vulnerability Status: If you change the status of a vulnerability, all instances associated with that vulnerability will automatically be set to the same status. For example, setting a vulnerability to Accepted Risk will update all instances within that vulnerability to Accepted Risk as well.
     
    2.  
  2.  
    Changing Instance Status: When modifying the status of individual instances within a vulnerability, the overall vulnerability status is recalculated based on its instances' statuses. The rules are as follows:
     
       
    • Confirmed Fix: For a vulnerability to be marked as Confirmed Fix, all instances must be set to Confirmed Fix. Even a single instance with a different status prevents the vulnerability from being marked as Confirmed Fix.
      •  
    • Vulnerable: If any instance is marked as Vulnerable, the entire vulnerability is marked as Vulnerable, regardless of other instances\u2019 statuses.
      •  
    • Accepted Risk: If all instances are marked as Accepted Risk, the vulnerability status will also be set to Accepted Risk.
      •  
     
    3.  
 
In short, for a vulnerability to be considered Confirmed Fix, all instances must be Confirmed Fix. To be marked as Accepted Risk, all instances must have that status. Any instance marked as Vulnerable will cause the vulnerability itself to be marked as Vulnerable.
"},{"location":"Features/project/project-view/","title":"Project View","text":"
APTRS allows users to create and manage projects, which are typically created when conducting a pentest for a company. When setting up a project, you can associate it with a specific company, select multiple internal users as project owners, and define key details such as project type, start and end dates, and a brief description.
 
Once the project is created, you can later add vulnerabilities, generate reports, and track progress within the project. This feature helps organize pentesting efforts efficiently, ensuring clear project ownership and structure.
 
"},{"location":"Features/project/project-view/#project-status","title":"Project Status","text":"
The project status is automatically calculated based on the project\u2019s start and end dates:
 
     
  • Upcoming: If the start date is in the future.
    •  
  • In Progress: If the start date has passed or is today, but the end date is still in the future.
    •  
  • Delayed: If the end date has passed.
    •  
  • Completed: If the project is marked as completed.
    •  
 
If your project is completed, you can manually mark it as Completed from the project summary. To do this, navigate to the project from the project table or dashboard, and you\u2019ll find an option to mark it as completed on the project summary page.
"},{"location":"Features/project/project-view/#project-details","title":"Project Details","text":"
Once a project is created, it is not possible to change the associated company. However, you can still edit other details, such as project type, dates, description, and owners.
"},{"location":"Features/project/project-view/#project-owners","title":"Project Owners","text":"
In Version 1.0, APTRS supports assigning multiple project owners, allowing you to add as many project owners as needed. Assigning or selecting a project owner requires admin privileges or the Assign Projects permission. Otherwise, the user creating the project is automatically added as the project owner.
"},{"location":"Features/project/report/","title":"Project Report","text":"
Once your project is ready, you can generate a report for the identified vulnerabilities. APTRS version 1.0 provides options to generate reports in PDF, Excel, and DOCX formats. Navigate to the report section within the project, select the desired report type and standard, and download the report directly.
 
 
As of version 1.0, the DOCX report generation feature is experimental. It may be removed or enhanced with more customization options in future versions. Once validated for full customization and consistent presentation, this feature will become permanent.
"},{"location":"Features/project/report/#report-customization","title":"Report Customization","text":"
You can customize both the PDF and DOCX reports:
 
     
  • PDF Reports: APTRS uses the WeasyPrint Python library to convert HTML into PDF. You can modify the HTML and CSS files used in report generation to match your requirements. 
    •  
  • DOCX Reports: APTRS leverages the python-docxtpl library to create DOCX files. The CKEditor WYSIWYG editor is used for entering vulnerability and project details. CKEditor\u2019s HTML output is then converted into DOCX format using the html2docx library, and integrated with docxtpl to generate the final report.
    •  
 
The HTML and DOCX report templates are available here: - HTML and DOCX Report Templates
 
CSS files for HTML-to-PDF reports can be customized here: - CSS for PDF Reports
"},{"location":"Features/project/report/#report-limitations","title":"Report Limitations","text":"
     
  • PDF Reports: APTRS uses the WeasyPrint Python library to generate PDF reports. However, WeasyPrint does not support JavaScript execution, which limits the ability to include custom, interactive charts directly within the PDF. Instead, APTRS generates charts using a Python library and embeds them as static images in the PDF. This approach restricts customization of charts via HTML and CSS.
    •  
  • DOCX Reports: APTRS generates DOCX reports using a combination of python-docx, python-docxtpl, and html2docx. While python-docxtpl enables dynamic content insertion into documents, it does not support updating or dynamically modifying charts. As a result, charts included in DOCX reports cannot be automatically updated with dynamic values by APTRS.
    •  
"},{"location":"Features/project/retest/","title":"Project Retest","text":"
Each project can have a retest task created and assigned to a user. Similar to a project, each retest includes a start and end date and has a designated retest owner. Retests allow you to specify the revalidation of the project\u2019s vulnerabilities, ensuring that fixes have been applied as expected. Within a project, users can initiate a retest to start this process.
 
 
Similar to project ownership, the retest owner is automatically set to the user creating the retest if they do not have admin privileges or the Assign Projects permission. Users with admin access or Assign Projects permission can select the retest owner. Once a retest task is created, it cannot be edited, though you can still delete the retest task if needed.
"},{"location":"Features/project/retest/#validation","title":"Validation","text":"
     
  • Project Completion Requirement: A retest task cannot be created if the project is not marked as completed. Retests are only applicable to projects that have been fully executed, as retests aim to validate resolved vulnerabilities. Therefore, a project must be completed before any retest can be initiated.
    •  
  • Single Active Retest Restriction: Even if the project is completed, you cannot create a new retest task if there is an existing retest task that is not marked as completed. Only one active retest can be associated with a project at a time.
    •  
"},{"location":"Features/project/scope/","title":"Project Scope","text":"
Each project includes scopes, allowing you to define the list of IPs, URLs, or application names that are part of the engagement. Starting from version 1.0, each project can have multiple scopes. Within the project page, you can navigate to the Scope section to manage the specific scope of the project.
 
"},{"location":"Features/vulnerabilityDB/vulnerability/","title":"Vulnerability DB (or Template)","text":"
The Vulnerability DB or Template feature in APTRS allows you to add and manage a database of vulnerabilities that can be reused across different projects. When adding a vulnerability to a project, you can specify all necessary details such as the title, description, solution, CVSS score, and more.
 
If you encounter the same vulnerability in multiple projects, such as IDOR or SQL Injection, the Vulnerability DB allows you to save time by reusing the same information without needing to write it again for each project. This helps streamline reporting and ensures consistency across projects.
 
By creating templates for common vulnerabilities, you can easily import them when adding vulnerabilities to new projects, reducing redundant work and improving efficiency.
 
"},{"location":"custom-report/docx/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/docx/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
     
  •  
    Description: 
     
    This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
     
    •  
  •  
    Usage Example:
     Python
    Company Who DID the Pentest: {{ mycompany }}\n
     
    •  
"},{"location":"custom-report/docx/company-user/#2-project-manager-users","title":"2. Project Manager Users","text":"
     
  •  
    Description:
     
    This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
     
    •  
  •  
    Usage Example:
     Python
    Project Managers:\n\n        {% for user in projectmanagers %}\n            {{ user.full_name }}  {{ user.position }} {{ user.email }}\n        {% endfor %}\n
     
    •  
"},{"location":"custom-report/docx/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
     
  •  
    Description:
     
    This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
     
    •  
  •  
    Usage Example:
     Text Only
        Customer Users:\n\n        {% for user in customeruser %}\n            {{ user.full_name }} {{ user.position }} {{ user.email }}\n        {% endfor %}\n
     
    •  
"},{"location":"custom-report/docx/docx/","title":"Docx","text":"
APTRS provides the ability to generate detailed DOCX reports using customizable templates. You can use Jinja2 template tags within your .docx templates to dynamically populate project and vulnerability data. This guide explains how to customize your template and use available context variables.
"},{"location":"custom-report/docx/docx/#template-location","title":"Template Location","text":"
The default template is located at: /APTRS/templates/report.docx
 
You can replace this file with your custom .docx template while keeping the required placeholders intact.
"},{"location":"custom-report/docx/docx/#using-template-tags","title":"Using Template Tags","text":"
The .docx template uses Jinja2 syntax for placeholders and loops. Below are some examples:
"},{"location":"custom-report/docx/docx/#placeholders","title":"Placeholders","text":"
     
  • Syntax: {{ variable_name }}
    •  
  • Example: To display the project name, use: {{ project.name }}
    •  
"},{"location":"custom-report/docx/docx/#loops","title":"Loops","text":"
     
  • Syntax: {% for item in items %}...{% endfor %}
    •  
  • Example: To list all vulnerabilities:
    •  
 Python
{% for vulnerability in vulnerabilities %}\n\n{{ vulnerability.vulnerabilityname }} (CVSS: {{ vulnerability.cvssscore }}) {% endfor %}\n
"},{"location":"custom-report/docx/docx/#conditional-statements","title":"Conditional Statements","text":"
     
  • Syntax: {% if condition %}...{% else %}...{% endif %}
    •  
  • Example: To check if a project has vulnerabilities:
    •  
 Python
{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n
"},{"location":"custom-report/docx/docx/#available-context-variables","title":"Available Context Variables","text":"Variable Description project The project object for which the report is being generated. Contains all project details. owners User details of All Project Owners project_exception Project Exceptions project_description Project Description vulnerabilities Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). mycomany The name of the internal (your company) company. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. projectscope Queryset of all project scopes for the project. totalretest List of retest schedules and owners. totalvulnerability Total count of vulnerabilities for the project. Report_type The type of report being generated (e.g., Audit, Re-Audit). standard The standard or methodology being used for the report. currentdate Get Current Date if needed in the report page_break Allows you to add page break in the docx report such as page break after each vulnerability details new_line Allows you to add a new line if needed"},{"location":"custom-report/docx/docx/#docx-formatting-with-jinja2","title":"Docx Formatting with Jinja2","text":"
By default, Jinja2 adds blank lines with conditions or loops, which can be problematic for Docx formatting. Unlike HTML, where empty lines have minimal impact, in Docx, this can lead to extra rows in tables or increased table width.
 
APTRS uses the docxtpl library, based on Python-docx and Jinja2, for template-based rendering. To reduce blank lines, you can use Jinja2's whitespace control.
 
However, this method doesn't always work flawlessly; it may inadvertently remove important elements like tables along with extra spaces. A simpler solution can involve using a single line of code.
 
You can modify the code like this:
 Python
##Instead of new line for code\n{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n\n\n## you can change it to like this on a single line \n\n{% if vulnerabilities %} Vulnerabilities are present. {% else %} No vulnerabilities found. {% endif %}\n
"},{"location":"custom-report/docx/docx/#color-and-conditions","title":"Color and Conditions","text":"
Each severity level in the report is represented by different colors: low or informational is often green or light blue, while high severity is red. Status can also be color-coded, with fixed vulnerabilities in green and open ones in red or orange.
 
In HTML reports, you can add severity values to the tag's class attribute and create CSS to apply the colors.
 
For DOCX reports, colors cannot be applied to undefined elements, limiting customization. To assign colors based on severity\u2014like red for critical and orange for high\u2014include them directly in the conditional statements within your DOCX template.
 Python
{% if severity == 'Critical' %} severity with red color. {% elif severity == 'Low' %} severity with green color. {% endif %}\n
 
 
Note
 
Adding Jinja2 White Space control to this will remove the color.
 
What if instead of just color for the text, we want to add color for the cell in the table like below  
 Name Status Severity SQL Injection Vulnerable Confirm Fixed 
We can do that as well with cellbg in the table, with hex color code like below:
 Python
{% cellbg 'FF491C' if vulnerability.vulnerabilityseverity== 'Critical' else 'F66E09' if vulnerability.vulnerabilityseverity== 'High' else 'FBBC02' if vulnerability.vulnerabilityseverity== 'Medium' else '20B803' if vulnerability.vulnerabilityseverity== 'Low' else '3399FF' %}{{ vulnerability.vulnerabilityseverity}}\n
 
"},{"location":"custom-report/docx/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/docx/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
     
  • Description:   Provides the total count of vulnerabilities associated with a project.
    •  
  • Usage Example:   You can display the total number of vulnerabilities for the project.
    •  
 Python
Total Vulnerabilities: {{ totalvulnerability }}\n
"},{"location":"custom-report/docx/other/#2-report-type","title":"2. Report Type","text":"
     
  • Description:   Specifies the type of report being generated. This can include types like \"Audit\" or \"Re-Audit\".
    •  
  • Usage Example:   Show the type of the report (Audit or Re-Audit).
    •  
 Python
  Report Type: {{ Report_type }}\n
"},{"location":"custom-report/docx/other/#3-report-standard","title":"3. Report Standard","text":"
     
  • Description:   The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
    •  
  • Usage Example:   Display the methodology or standard used in the vulnerability report.
    •  
 Python
  Report Standard: {{ standard|join(', ') }} \n
"},{"location":"custom-report/docx/other/#4-current-date","title":"4. Current Date","text":"
     
  •  
    Description:   Get the current date if needed in the report.
     
    •  
  •  
    Usage Example: Python
    Report Generated On: {{ currentdate }}   \n# OR\n{{ currentdate.strftime('%B %d, %Y') }}\n
     
    •  
"},{"location":"custom-report/docx/other/#5-page-break","title":"5.  Page Break","text":"
     
  •  
    Description:    Allows you to add a page break in the DOCX report, such as after each vulnerability's details.
     
    •  
  •  
    Usage Example: Python
      {% if vulnerability %}\n  {{ page_break }}\n  {% endif %}\n
     
    •  
"},{"location":"custom-report/docx/other/#6-new-line","title":"6. New Line","text":"
     
  •  
    Description:    Allows you to add a new line if needed in the report.
     
    •  
  •  
    Usage Example: Python
      Vulnerability Details:  \n  CVSS Score{{ new_line }} 8.8\n
     
    •  
"},{"location":"custom-report/docx/project/","title":"Project","text":""},{"location":"custom-report/docx/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report Docx, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/docx/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
     
  1.  
    project.name 
     
       
    • Represents the name of the project.  
      •  
    • Example usage in HTML: Python
      Project Name: {{ project.name }}\n
      •  
     
    2.  
  2.  
    project.companyname 
     
       
    • A foreign key to the Company model, representing the company associated (Customer Company) with the project.  
      •  
    • Example usage: Python
      Company Name: {{ project.companyname.name }}\n
      •  
     
    3.  
  3.  
    project_exception 
     
       
    • A detailed description of the project.  
      •  
    • Example usage: Python
      Description: {{p project_exception}}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    4.  
  4.  
    project.projecttype 
     
       
    • Specifies the type of project.  
      •  
    • Example usage: Python
      Project Type: {{ project.projecttype }}\n
      •  
     
    5.  
  5.  
    project.startdate 
     
       
    • The start date of the project.  
      •  
    • Example usage: Python
      Start Date: {{ project.startdate }}\n
      •  
    • You can also modify the date format      Python
          Project Start Date: {{ project.startdate.strftime(\"%d/%m/%Y\") }}\n
      •  
     
    6.  
  6.  
    project.enddate 
     
       
    • The end date of the project.  
      •  
    • Example usage: Python
      <End Date: {{ project.enddate }}\n
      •  
    • You can also modify the date format      Python
          Project End Date: {{project.enddate.strftime(\"%d/%m/%Y\") }}\n
      •  
     
    7.  
  7.  
    project.testingtype 
     
       
    • The type of testing performed for the project (e.g., White Box, Black Box).  
      •  
    • Example usage: Python
      Testing Type: {{ project.testingtype }}\n
      •  
     
    8.  
  8.  
    project_exception 
     
       
    • Notes or exceptions for the project, if any.  
      •  
    • Example usage: Python
      Exceptions: {{p project_exception }}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
    • In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions.   Python
      {% if project_exception %}\nExceptions: {{p project_exception }}\n{% endif %}\n
      •  
     
    9.  
  9.  
    project.owner 
     
       
    • Note: This is not available, due to issues with the method provided by django to loop many to many database relation, it does not work with the jinja2. 
      •  
     
    10.  
  10.  
    project.status 
     
       
    • The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).  
      •  
    • Example usage: Python
      Status: {{ project.status }}\n
      •  
     
    11.  
 
In order to get Project owner details, APTRS provide a seperate context and tag owners which contain user details for project owners. In order to use it you have to loop through details like below:
 Python
      {% for owner in owners %}\n        {{ owner.full_name}}\n        {{ owner.email}}\n        {{ owner.position}}\n        {{ owner.number}}\n      {% endfor %}\n
"},{"location":"custom-report/docx/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status. 
 
     
  • Usage Example:   You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
    •  
 Python
  Project Retests:\n\n      {% for retest in totalretest %}\n          {{ retest.startdate }}  {{ retest.enddate }} | Status: {{ retest.status }}\n\n                  {% for owner in retest.owners %}\n                      {{ owner }}\n                  {% endfor %}\n\n      {% endfor %}\n
 
Note
 
The {{ owner }} will only show the full_name of the owner, as of now its limited to full name only.
 
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
 HTML
{% if Report_type == 'Re-Audit' %}\n  Project Retests:\n\n      {% for retest in totalretest %}\n          {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n                {% for owner in retest.owners %}\n                      {{ owner }}\n                  {% endfor %}\n\n      {% endfor %}\n\n{% endif %}\n
"},{"location":"custom-report/docx/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
 
     
  • Usage Example:
    •  
 Python
Project Scope:\n\n    {% for scope in projectscope %}\n        {{ scope.scope }}  {{ scope.description }}\n    {% endfor %}\n</ul>\n
"},{"location":"custom-report/docx/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/docx/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. APTRS provide {{vulnerabilities}} tag with list of all vulnerabilities and its instances. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/docx/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
     
  1.  
    vulnerability.vulnerabilityname 
     
       
    • The name of the vulnerability (e.g., \"SQL Injection\").  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nVulnerability Name: {{ vulnerability.vulnerabilityname }}\n{% endfor %}\n
      •  
     
    2.  
  2.  
    vulnerability.vulnerabilityseverity 
     
       
    • The severity of the vulnerability (e.g., \"High\", \"Medium\").  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nSeverity: {{ vulnerability.vulnerabilityseverity }}\n{% endfor %}\n
      •  
     
    3.  
  3.  
    vulnerability.cvssscore 
     
       
    • The CVSS score associated with the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCVSS Score: {{ vulnerability.cvssscore }}\n{% endfor %}\n
      •  
     
    4.  
  4.  
    vulnerability.cvssvector 
     
       
    • The CVSS vector associated with the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCVSS Vector: {{ vulnerability.cvssvector }}\n{% endfor %}\n
      •  
     
    5.  
  5.  
    vulnerability.status 
     
       
    • The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nStatus: {{ vulnerability.status }}\n{% endfor %}\n
      •  
     
    6.  
  6.  
    vulnerability.vulnerabilitydescription 
     
       
    • A description of the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nDescription: {{p vulnerability.vulnerabilitydescription }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    7.  
  7.  
    vulnerability.POC 
     
       
    • The proof of concept (POC) for the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nPOC: {{p vulnerability.POC }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    8.  
  8.  
    vulnerability.vulnerabilitysolution 
     
       
    • The recommended solution for the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nSolution: {{p vulnerability.vulnerabilitysolution }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    9.  
  9.  
    vulnerability.vulnerabilityreferlnk 
     
       
    • A reference link related to the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nReference Link: {{p vulnerability.vulnerabilityreferlnk }}\n{% endfor %}\n
      •  
    • It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
      •  
     
    10.  
  10.  
    vulnerability.created 
     
       
    • The timestamp when the vulnerability was created.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCreated: {{ vulnerability.created }}\n{% endfor %}\n
      •  
     
    11.  
  11.  
    vulnerability.created_by 
     
       
    • The user who created the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nCreated By: {{ vulnerability.created_by.username }}\n{{ vulnerability.created_by.full_name }}\n{% endfor %}\n
      •  
    • Similar to project owner, you can use other filed as well  like email, number or postion etc.
      •  
     
    12.  
  12.  
    vulnerability.last_updated_by 
     
       
    • The user who last updated the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\nLast Updated By: {{ vulnerability.last_updated_by.username }}\n{{ vulnerability.last_updated_by.full_name }}\n{% endfor %}\n
      •  
     
    13.  
  13.  
    vulnerability.instances_data 
     
       
    • Acess all instaces of the vulnerability.  
      •  
    • Example usage: Python
      {% for vulnerability in vulnerabilities %}\n\n      {for instance in vulnerability.instances_data %}\n      ## This give all instances for vulnerabiltiy in current loop\n\n        URL: {{ instance.URL }}\n        Parameter: {{ instance.Parameter }}\n        Parameter: {{ instance.Status }}\n\n      {% endfor %}\n\n{% endfor %}\n
      •  
     
    14.  
"},{"location":"custom-report/docx/vulnerability/#example","title":"Example","text":"Python
{% for vulnerability in vulnerabilities %}\n\n    Vulnerability Name: {{ vulnerability.vulnerabilityname }}\n\n    Severity: {{ vulnerability.vulnerabilityseverity }}\n\n    CVSS Score: {{ vulnerability.cvssscore }}\n\n    CVSS Vector: {{ vulnerability.cvssvector }}\n\n    Status: {{ vulnerability.status }}\n\n    Description:  \n    {{p vulnerability.vulnerabilitydescription }}\n\n    POC:  \n    {{p vulnerability.POC }}\n\n    Solution:  \n    {{p vulnerability.vulnerabilitysolution }}\n\n    Reference Link:  \n    {{p vulnerability.vulnerabilityreferlnk }}\n\n    Created On: {{ vulnerability.created }}\n\n    Created By:  \n    - Username: {{ vulnerability.created_by.username }}  \n    - Full Name: {{ vulnerability.created_by.full_name }}\n    - Email: {{ vulnerability.created_by.email }}\n    - Number: {{ vulnerability.created_by.number }}\n\n    Last Updated By:  \n    - Username: {{ vulnerability.last_updated_by.username }}\n    - Full Name: {{ vulnerability.last_updated_by.full_name }}\n    - Email: {{ vulnerability.last_updated_by.email }}\n    - Number: {{ vulnerability.last_updated_by.number }}\n\n    Instances\n\n      {for instance in vulnerability.instances_data %}\n\n        URL: {{ instance.URL }}\n        Parameter: {{ instance.Parameter }}\n        Parameter: {{ instance.Status }}\n\n      {% endfor %}\n\n{% endfor %}\n
"},{"location":"custom-report/docx/vulnerability/#reference","title":"Reference","text":"
For reference you can see vulnerabilities tag as below json object
 JSON
vulnerabilities = [\n    {\n        \"project\": \"Project Name or ID\",  \n        \"vulnerabilityname\": \"SQL Injection in Login Page\",\n        \"vulnerabilityseverity\": \"High\",\n        \"cvssscore\": 9.8,\n        \"cvssvector\": \"AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\n        \"status\": \"Vulnerable\",\n        \"vulnerabilitydescription\": \"Converted DOCX content for vulnerability 1 description\",\n        \"POC\": \"Converted DOCX content for vulnerability 1 proof of concept\",\n        \"created\": \"2024-11-20T10:15:30Z\",\n        \"vulnerabilitysolution\": \"Converted DOCX content for vulnerability 1 solution\",\n        \"vulnerabilityreferlnk\": \"Converted DOCX content for vulnerability 1 reference link\",\n        \"created_by\": \"User1\",\n        \"last_updated_by\": \"User2\",\n        \"instances_data\": [\n            {\n                \"URL\": \"https://example.com/vulnerable-endpoint-1\",\n                \"Parameter\": \"user_id\",\n                \"Status\": \"Open\"\n            },\n            {\n                \"URL\": \"https://example.com/another-endpoint-1\",\n                \"Parameter\": \"\",\n                \"Status\": \"Closed\"\n            }\n        ]\n    },\n    {\n        \"project\": \"Project Name or ID\",  \n        \"vulnerabilityname\": \"Cross-Site Scripting in Search Page\",\n        \"vulnerabilityseverity\": \"Medium\",\n        \"cvssscore\": 6.5,\n        \"cvssvector\": \"AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N\",\n        \"status\": \"Vulnerable\",\n        \"vulnerabilitydescription\": \"Converted DOCX content for vulnerability 2 description\",\n        \"POC\": \"Converted DOCX content for vulnerability 2 proof of concept\",\n        \"created\": \"2024-11-19T14:10:45Z\",\n        \"vulnerabilitysolution\": \"Converted DOCX content for vulnerability 2 solution\",\n        \"vulnerabilityreferlnk\": \"Converted DOCX content for vulnerability 2 reference link\",\n        \"created_by\": \"User3\",\n        \"last_updated_by\": \"User4\",\n        \"instances_data\": [\n            {\n                \"URL\": \"https://example.com/vulnerable-endpoint-2\",\n                \"Parameter\": \"session_id\",\n                \"Status\": \"Open\"\n            },\n            {\n                \"URL\": \"https://example.com/another-endpoint-2\",\n                \"Parameter\": \"order_id\",\n                \"Status\": \"Closed\"\n            }\n        ]\n    }\n]\n
"},{"location":"custom-report/pdf/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/pdf/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
     
  •  
    Description: 
     
    This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
     
    •  
  •  
    Usage Example:
     HTML
    <p>Company: {{ mycompany }}</p>\n
     
    •  
"},{"location":"custom-report/pdf/company-user/#2-project-manager-users","title":"2. Project Manager Users","text":"
     
  •  
    Description:
     
    This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
     
    •  
  •  
    Usage Example:
     HTML
    <h3>Project Managers:</h3>\n    <ul>\n        {% for user in projectmanagers %}\n            <li>{{ user.full_name }} - {{ user.position }}</li>\n        {% endfor %}\n    </ul>\n
     
    •  
"},{"location":"custom-report/pdf/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
     
  •  
    Description:
     
    This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
     
    •  
  •  
    Usage Example:
     HTML
        <h3>Customer Users:</h3>\n    <ul>\n        {% for user in customeruser %}\n            <li>{{ user.full_name }} - {{ user.position }}</li>\n        {% endfor %}\n    </ul>\n
     
    •  
"},{"location":"custom-report/pdf/context-variable/","title":"Context Variable","text":"
This document describes how to customize the HTML templates used to generate PDF reports using the GetHTML function in your Django application. Below are the available context variables that can be used in the HTML templates and their respective details.
"},{"location":"custom-report/pdf/context-variable/#context-variables","title":"Context Variables","text":"
The following context variables are passed to the HTML template (report.html) during PDF generation. Users can use these variables to dynamically customize the content of the PDF report.
 Variable Name Description project The project object for which the report is being generated. Contains all project details. vuln Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). instances Queryset of all vulnerable instances associated with the project. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. mycomany The name of the internal (your company) company. projectscope Queryset of all project scopes for the project. totalretest Queryset of all retests for the project. totalvulnerability Total count of vulnerabilities for the project. ciritcal Count of vulnerabilities with severity \"Critical\". high Count of vulnerabilities with severity \"High\". medium Count of vulnerabilities with severity \"Medium\". low Count of vulnerabilities with severity \"Low\". info Count of vulnerabilities with severity \"Informational\" or \"None\". standard The standard or methodology being used for the report. Report_type The type of report being generated (e.g., Audit, Re-Audit). pie_chart Rendered pie chart data showing the vulnerability distribution by severity."},{"location":"custom-report/pdf/context-variable/#how-to-customize-templates","title":"How to Customize Templates","text":"
     
  1.  
    Locate the HTML Template: 
     
       
    • The report template is located at templates/*. You can modify this file or create a new one for different report types.
      •  
     
    2.  
  2.  
    Use Context Variables: 
     
       
    • Insert the context variables into the template using Django's template syntax. For example:     HTML
      <h1>Vulnerability Report for {{ project.name }}</h1>\n<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n<p>Critical Issues: {{ ciritcal }}</p>\n<p>High Severity Issues: {{ high }}</p>\n
      •  
     
    3.  
  3.  
    Dynamic Content:
     
       
    • Use loops and conditionals to dynamically render data. For example:     HTML
      <ul>\n{% for vuln in vuln %}\n    <li>{{ vuln.vulnerabilityname }} - Severity: {{ vuln.vulnerabilityseverity }}</li>\n{% endfor %}\n</ul>\n
      •  
     
    4.  
  4.  
    Styling and Charts:
     
       
    • Use {{ pie_chart|safe }} to embed the rendered pie chart in the HTML. Ensure that the safe filter is applied to include raw HTML safely.
      •  
     
    5.  
"},{"location":"custom-report/pdf/context-variable/#example-template-usage","title":"Example Template Usage","text":"
Here\u2019s a sample section of the report.html template:
 HTML
<!DOCTYPE html>\n<html>\n<head>\n    <title>{{ project.name }} Vulnerability Report</title>\n</head>\n<body>\n    <h1>{{ mycomany }} - Vulnerability Report</h1>\n    <h2>Project: {{ project.name }}</h2>\n    <p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n    <p>Critical Issues: {{ ciritcal }}</p>\n    <p>High Severity Issues: {{ high }}</p>\n    <p>Medium Severity Issues: {{ medium }}</p>\n    <p>Low Severity Issues: {{ low }}</p>\n    <p>Informational Issues: {{ info }}</p>\n\n    <h3>Vulnerability Breakdown</h3>\n    {{ pie_chart|safe }}\n\n    <h3>Vulnerabilities</h3>\n    <ul>\n        {% for v in vuln %}\n            <li>{{ v.vulnerabilityname }} - Severity: {{ v.vulnerabilityseverity }}</li>\n        {% endfor %}\n    </ul>\n</body>\n</html>\n
"},{"location":"custom-report/pdf/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/pdf/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
     
  • Description:   Provides the total count of vulnerabilities associated with a project.
    •  
  • Usage Example:   You can display the total number of vulnerabilities for the project.
    •  
 HTML
<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n
"},{"location":"custom-report/pdf/other/#2-severity-count","title":"2. Severity Count","text":"
     
  • Description:   Shows the count of vulnerabilities that have a severity of Critical or High, Medium, Low, None.
    •  
  • Usage Example:   You can display the severity count.
    •  
 HTML
  <p>Critical Vulnerabilities: {{ critical }}</p>\n  <p>High Vulnerabilities: {{ high }}</p>\n  <p>Medium Vulnerabilities: {{ medium }}</p>\n  <p>Low Vulnerabilities: {{ low }}</p>\n  <p>Informational Vulnerabilities: {{ info }}</p>\n
"},{"location":"custom-report/pdf/other/#3-report-standard","title":"3. Report Standard","text":"
     
  • Description:   The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
    •  
  • Usage Example:   Display the methodology or standard used in the vulnerability report.
    •  
 HTML
  <p>Report Standard: {{ standard|join:\", \" }}</p>\n
"},{"location":"custom-report/pdf/other/#4-report-type","title":"4. Report Type","text":"
     
  • Description:   Specifies the type of report being generated. This can include types like \"Audit\" or \"Re-Audit\".
    •  
  • Usage Example:   Show the type of the report (Audit or Re-Audit).
    •  
 HTML
  <p>Report Type: {{ Report_type }}</p>\n
"},{"location":"custom-report/pdf/other/#5-chart-image","title":"5. Chart Image","text":"
     
  • Description:   This variable holds the rendered data for a pie chart showing the distribution of vulnerabilities by severity.
    •  
  • Usage Example:   Use this to display a pie chart visualizing vulnerability severity distribution.
    •  
 HTML
  <div>{{ pie_chart|safe }}</div>\n
"},{"location":"custom-report/pdf/pdf/","title":"Customized PDF Report Documentation","text":"
APTRS uses the WeasyPrint library to generate PDF reports from HTML and CSS. The Django template engine dynamically passes data to the HTML template using context variables. 
"},{"location":"custom-report/pdf/pdf/#how-it-works","title":"How It Works","text":"
The system is designed so you don\u2019t need to edit the Django code that handles report generation unless you are familiar with Django and Python. The recommended approach is to customize the layout and styling by modifying the HTML and CSS files provided with the project.
"},{"location":"custom-report/pdf/pdf/#file-structure-for-customization","title":"File Structure for Customization","text":"
Within the project root directory, there is a subdirectory named APTRS. This contains the following important folders for report customization:
 
     
  1.  
    Static Folder:  
     
       
    • Located inside the APTRS directory.  
      •  
    • Contains a CSS subfolder where all CSS files for the report are stored.  
      •  
    • Includes predefined styles that you can customize to adjust the appearance of the report.
      •  
     
    2.  
  2.  
    Templates Folder:  
     
       
    • Located in the same directory as the static folder.  
      •  
    • Contains all the HTML templates used for generating reports.  
      •  
    • Templates are modular, with the main report layout in report.html and additional reusable components loaded using Django's {% include %} tag.
      •  
     
    3.  
"},{"location":"custom-report/pdf/pdf/#key-files-for-customization","title":"Key Files for Customization","text":"
     
  1.  
    report.html:
     
       
    • The main HTML file for the report.  
      •  
    • Includes the overall structure, head tags, and references to CSS files.  
      •  
    • Dynamically includes other HTML components for better modularity.
      •  
     
    2.  
  2.  
    report-page.css:
     
       
    • The primary CSS file applied to all report pages.  
      •  
    • Handles global styles such as font loading, page numbering, table styles, and default styles for HTML tags.  
      •  
    • Defines general formatting applied across the entire report.
      •  
     
    3.  
  3.  
    Component Files:
     
       
    • Each HTML file has a corresponding CSS file for specific styles.
      •  
    • For example, styles specific to an HTML section like vulnerability.html will be defined in vulnerability.css.
      •  
    • This structure ensures easy identification and modification of styles tied to specific sections.
      •  
     
    4.  
"},{"location":"custom-report/pdf/pdf/#fonts","title":"Fonts","text":"
The project uses the Fira Sans font by default, stored in the static/fonts folder. You can:
 
     
  • Add new fonts to the fonts folder.
    •  
  • Update the CSS in the report-page.css file to use your fonts.
    •  
"},{"location":"custom-report/pdf/pdf/#customization-tips","title":"Customization Tips","text":"
     
  • Modify HTML files to change content layout, add new sections, or reorder components.
    •  
  • Edit CSS files to change colors, fonts, or styles for specific sections.
    •  
  • Use the modular structure to quickly locate and modify styles for individual components.
    •  
  • For global styles or formatting (e.g., page numbers, headers, footers), update report-page.css.
    •  
"},{"location":"custom-report/pdf/pdf/#important-notes","title":"Important Notes","text":"
     
  • Avoid editing the Django code unless necessary, as it handles the logic for passing variables and generating the PDF.
    •  
  • All changes to the static files (CSS) or templates (HTML) will reflect in the next report generated.
    •  
"},{"location":"custom-report/pdf/project/","title":"Project","text":""},{"location":"custom-report/pdf/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report HTML, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/pdf/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
     
  1.  
    project.name 
     
       
    • Represents the name of the project.  
      •  
    • Example usage in HTML: HTML
      <h1>Project Name: {{ project.name }}</h1>\n
      •  
     
    2.  
  2.  
    project.companyname 
     
       
    • A foreign key to the Company model, representing the company associated (Customer Company) with the project.  
      •  
    • Example usage: HTML
      <p>Company Name: {{ project.companyname.name }}</p>\n
      •  
     
    3.  
  3.  
    project.description 
     
       
    • A detailed description of the project.  
      •  
    • Example usage: HTML
      <p>Description: {{project.description|clean_html}}</p>\n
      •  
    • It uses CKeditor HTML data, using |clean_html allow to render html data securely instead of as text.
      •  
     
    4.  
  4.  
    project.projecttype 
     
       
    • Specifies the type of project.  
      •  
    • Example usage: HTML
      <p>Project Type: {{ project.projecttype }}</p>\n
      •  
     
    5.  
  5.  
    project.startdate 
     
       
    • The start date of the project.  
      •  
    • Example usage: HTML
      <p>Start Date: {{ project.startdate }}</p>\n
      •  
    • You can also modify the date format      HTML
          <p>Start Date: {{project.startdate|date:\"d/m/Y\" }} </p>\n
      •  
     
    6.  
  6.  
    project.enddate 
     
       
    • The end date of the project.  
      •  
    • Example usage: HTML
      <p>End Date: {{ project.enddate }}</p>\n
      •  
    • You can also modify the date format      HTML
          <p>End Date: {{project.enddate|date:\"d/m/Y\" }} </p>\n
      •  
     
    7.  
  7.  
    project.testingtype 
     
       
    • The type of testing performed for the project (e.g., White Box, Black Box).  
      •  
    • Example usage: HTML
      <p>Testing Type: {{ project.testingtype }}</p>\n
      •  
     
    8.  
  8.  
    project.projectexception 
     
       
    • Notes or exceptions for the project, if any.  
      •  
    • Example usage: HTML
      <p>Exceptions: {{ project.projectexception|clean_html }}</p>\n
      •  
    • It uses CKeditor HTML data, using |clean_html allow to render html data securely instead of as text.
      •  
    • In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions.   HTML
      {% if project.projectexception %}\n<p>Exceptions: {{ project.projectexception|clean_html }}</p>\n{% endif %}\n
      •  
     
    9.  
  9.  
    project.owner 
     
       
    • A many-to-many relationship representing users associated as owners of the project.  
      •  
    • To display all owners: HTML
      <ul>\n  {% for owner in project.owner.all %}\n    <li>{{ owner.username }}</li>\n    <li>{{ owner.full_name }} </li>\n    <td>{{ owner.email }} </li>\n    <li>{{ owner.number }} </li>\n    <li>{{ owner.position }} </li>\n  {% endfor %}\n</ul>\n
      •  
     
    10.  
  10.  
    project.status 
     
       
    • The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).  
      •  
    • Example usage: HTML
      <p>Status: {{ project.status }}</p>\n
      •  
     
    11.  
"},{"location":"custom-report/pdf/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status. 
 
     
  • Usage Example:   You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
    •  
 HTML
<h3>Project Retests:</h3>\n  <ul>\n      {% for retest in totalretest %}\n          <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n              {% for owner in retest.owner.all %}\n                    {{ owner.full_name }}\n\n              {% endfor %}\n          </li>\n      {% endfor %}\n  </ul>\n
 
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
 HTML
{% if Report_type == 'Re-Audit' %}\n  <h3>Project Retests:</h3>\n  <ul>\n      {% for retest in totalretest %}\n          <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n            {% for owner in retest.owner.all %}\n                    {{ owner.full_name }}\n\n              {% endfor %}\n          </li>\n      {% endfor %}\n  </ul>\n{% endif %}\n
"},{"location":"custom-report/pdf/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
 
     
  • Usage Example:
    •  
 HTML
<h3>Project Scope:</h3>\n<ul>\n    {% for scope in projectscope %}\n        <li>{{ scope.scope }} - {{ scope.description }}</li>\n    {% endfor %}\n</ul>\n
"},{"location":"custom-report/pdf/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/pdf/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
     
  1.  
    vulnerability.vulnerabilityname 
     
       
    • The name of the vulnerability (e.g., \"SQL Injection\").  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n{% endfor %}\n
      •  
     
    2.  
  2.  
    vulnerability.vulnerabilityseverity 
     
       
    • The severity of the vulnerability (e.g., \"High\", \"Medium\").  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n{% endfor %}\n
      •  
     
    3.  
  3.  
    vulnerability.cvssscore 
     
       
    • The CVSS score associated with the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>CVSS Score: {{ vulnerability.cvssscore }}</p>\n{% endfor %}\n
      •  
     
    4.  
  4.  
    vulnerability.cvssvector 
     
       
    • The CVSS vector associated with the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n{% endfor %}\n
      •  
     
    5.  
  5.  
    vulnerability.status 
     
       
    • The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Status: {{ vulnerability.status }}</p>\n{% endfor %}\n
      •  
     
    6.  
  6.  
    vulnerability.vulnerabilitydescription 
     
       
    • A description of the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n{% endfor %}\n
      •  
     
    7.  
  7.  
    vulnerability.POC 
     
       
    • The proof of concept (POC) for the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n{% endfor %}\n
      •  
     
    8.  
  8.  
    vulnerability.vulnerabilitysolution 
     
       
    • The recommended solution for the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Solution: {{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n{% endfor %}\n
      •  
     
    9.  
  9.  
    vulnerability.vulnerabilityreferlnk 
     
       
    • A reference link related to the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Reference Link: {{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n{% endfor %}\n
      •  
     
    10.  
  10.  
    vulnerability.created 
     
       
    • The timestamp when the vulnerability was created.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Created: {{ vulnerability.created }}</p>\n{% endfor %}\n
      •  
     
    11.  
  11.  
    vulnerability.created_by 
     
       
    • The user who created the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Created By: {{ vulnerability.created_by.username }}</p>\n{{ vulnerability.created_by.full_name }}</p>\n{% endfor %}\n
      •  
    • Similar to project owner, you can use other filed as well  like email, number or postion etc.
      •  
     
    12.  
  12.  
    vulnerability.last_updated_by 
     
       
    • The user who last updated the vulnerability.  
      •  
    • Example usage: HTML
      {% for vulnerability in vuln %}\n<p>Last Updated By: {{ vulnerability.last_updated_by.username }}</p>\n{% endfor %}\n
      •  
     
    13.  
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerableinstance-model","title":"Available Variables for Vulnerableinstance Model","text":"
     
  1. instance.vulnerabilityid 
    2.  
  2. The Vulnerability object associated with the instance.  
    3.  
  3.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Vulnerability Name: {{ instance.vulnerabilityid.vulnerabilityname }}</p>\n{% endfor %}\n
     
    4.  
  4.  
    instance.project 
     
    5.  
  5. The project associated with the vulnerable instance.  
    6.  
  6.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Project: {{ instance.project.name }}</p>\n{% endfor %}\n
     
    7.  
  7.  
    instance.URL 
     
    8.  
  8. The URL of the vulnerable instance.  
    9.  
  9.  
    Example usage: HTML
    {% for instance in instances %}\n<p>URL: {{ instance.URL }}</p>\n{% endfor %}\n
     
    10.  
  10.  
    instance.Parameter 
     
    11.  
  11. The parameter of the vulnerable instance.  
    12.  
  12.  
    Example usage: HTML
    {% for instance in instances %}\n<p>Parameter: {{ instance.Parameter }}</p>\n{% endfor %}\n
     
    13.  
  13.  
    instance.status 
     
    14.  
  14. The status of the vulnerable instance, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).  
    15.  
  15. Example usage: HTML
    {% for instance in instances %}\n<p>Status: {{ instance.status }}</p>\n{% endfor %}\n
    16.  
"},{"location":"custom-report/pdf/vulnerability/#displaying-vulnerable-instances-for-a-specific-vulnerability-in-a-template","title":"Displaying Vulnerable Instances for a Specific Vulnerability in a Template","text":"
The instances query set or list does not associate with the vulnerability name, instances variable contain all instances for the project, In most cases we need all instances for a vulnerability. We can do that as well, you can check in the original vulnerabilities.html in the template or you can use this: 
 
To display the instances for a specific vulnerability within a loop for vulnerabilities, you can use the following approach:
 HTML
{% for vulnerability in vuln %}\n\n <p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n\n<p>{{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n\n<p>{{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n\n  <p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n\n   <p>Status: {{ vulnerability.status }}</p>\n\n   <p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n\n   <p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n\n  {% for instance in instances %}\n\n    {% if instance.vulnerabilityid.id == vulnerability.id %}\n      <tr>\n        <td>{{ instance.URL }}</td>\n        <td>{{ instance.Parameter }}</td>\n        <td>{{ instance.status }}</td>\n      </tr>\n    {% endif %}\n\n  {% endfor %}\n\n{% endfor %}\n
"},{"location":"getting-started/Contribution/","title":"Project Contribution","text":""},{"location":"getting-started/Contribution/#project-contribution","title":"Project Contribution","text":""},{"location":"getting-started/Contribution/#creator","title":"Creator","text":"
     
  • Sourav Kalal
    •  
"},{"location":"getting-started/Contribution/#special-thanks","title":"Special Thanks","text":"
     
  •  
    DJ Scruggs A big thanks to DJ Scruggs for creating the entire ViteJS frontend from scratch and implementing the APIs for version 1.0.
     
       
    • GitHub
      •  
    • Portfolio
      •  
    • LinkedIn
      •  
     
    •  
"},{"location":"getting-started/Contribution/#mention","title":"Mention","text":"
Yonathan johnson Started creating the frontend using React. Although he could not complete the development due to certain circumstances, his initiative and effort are greatly appreciated.
"},{"location":"getting-started/Features/","title":"Features","text":""},{"location":"getting-started/Features/#features","title":"Features","text":"
     
  •  
    Automated Report Generation: APTRS automates creating comprehensive penetration testing reports, saving time and ensuring consistency.
     
    •  
  •  
    PDF Docx, and Excel Reports: Generate professional-looking PDF, Docx and Excel reports with ease, providing clients and stakeholders with clear insights into security assessments.
     
    •  
  •  
    Vulnerability Management: APTRS helps you keep track of vulnerabilities across different projects, allowing for efficient management and mitigation.
     
    •  
  •  
    User-Friendly Interface: The tool is designed with a user-friendly interface, making it accessible for both novice and experienced penetration testers.
     
    •  
  •  
    Customization: Tailor your reports to meet specific project requirements, ensuring that the generated reports align with your organization's standards.
     
    •  
  •  
    Project and Customer Management: Manage all your projects, retest, and customer all in one place. The user and project tracking allows you to monitor the user's project allocation, plans, and status.
     
    •  
"},{"location":"getting-started/Sponsors/","title":"Sponsors","text":"
     
  • Many thanks to DigitalOcean for their generous support of the project.
    •  
"},{"location":"getting-started/demo/","title":"Demo","text":""},{"location":"getting-started/demo/#live-demo-instance","title":"Live Demo Instance","text":"
Explore the features of APTRS through our live demo instance:
 
     
  • Live Demo
    •  
  • Username: sourav.kalal@aptrs.com
    •  
  • Password: I-am-Weak-Password-Please-Change-Me
    •  
 
Feel free to interact with the tool and see how APTRS can streamline your penetration testing workflows.
 
\ud83c\udf28\ufe0f Huge thanks to DigitalOcean for their support of the APTRS project.
 
Warning
 
\ud83d\udea7 APIs related to user profiles and user management, such as adding, editing, deleting users, and changing passwords, are disabled on the cloud-hosted demo instance.
"},{"location":"getting-started/license/","title":"License","text":"
The APTRS project is released under the MIT License, which is a permissive open-source license allowing anyone to use, modify, and distribute the software freely. This license ensures that the software remains open and accessible while permitting both personal and commercial use, provided that the original copyright notice and license terms are included in all copies or substantial portions of the software
"},{"location":"installation/certificate/","title":"Secure Certificate","text":"
APTRS uses HTTPS with a self-signed certificate. If you would like to replace the self-signed certificate with your own, you can do so by updating the certificate and key files located at:
 
https://github.com/APTRS/APTRS/tree/main/Certificate
"},{"location":"installation/docker/","title":"Docker","text":""},{"location":"installation/docker/#linux","title":"Linux","text":"Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncp env.docker .env\nnano .env\ndocker-compose up \n
"},{"location":"installation/docker/#windows","title":"Windows","text":"Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncopy env.docker .env\nnotepad .env\ndocker-compose up \n
 
Note
 
The .env file contains all the environment variables, such as passwords for JWT, Database credentials, Cloud S3 bucket details, etc. It\u2019s important to update the default passwords and details before deploying the application. For more information, refer to the Environment Variables section.
"},{"location":"installation/env/","title":"Environment Variables","text":"
The APTRS backend uses the .env file to store credentials such as S3 bucket information, database credentials, secret keys, whitelisted IPs/domains, and more.
 
     
  • If you are deploying the application with Docker, make sure to update the details in the .env file from the project root.
    •  
  • If you are deploying the application without Docker, you will need to update specific details like the S3 bucket and whitelisted IPs.
    •  
 ENV Description Docker Linux Server Manual Setup SECRET_KEY This key is used by Backend including JWT, Should be secured and random. Manually need to be updated in env file Manually need to be updated in env file WHITELIST_IP This allows to set whitelisted IP/domain with port number to allow loading resource during PDF report to prevent SSRF vulnerability. Manually need to be updated in env file, make sure to keep the https://nginx as its required to connect with nginx within Docker Manually need to be updated in env file based on your domain name, IP etc. ALLOWED_HOST Whitelist allowed host to prevent host header injection attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. CORS_ORIGIN Whitelist allowed origin to prevent cross origin attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. REDIS_URL Redis Server Details including IP, Port and password Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Do not update other details except password Manually need to be updated in env file for REDIS password, IP and Port details REDIS_PASSWORD Redis Server password for Redis image in docker Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Password in REDIS_URL  and REDIS_PASSWORD should be same Not needed and no need to update/add. POSTGRES_USER , POSTGRES_PASSWORD, POSTGRES_PORT, POSTGRES_DB Postgres DB username, password, port, and DB names Manually need to be updated in env file Manually need to be updated in env file. POSTGRES_HOST Postgres host name Should not be updated. Manually need to be updated in env file. USE_S3 If you want to use Cloud S3 bucket Digital Ocean or AWS s3 bucket. Default False, you can change it to True Optional Optional AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_STORAGE_BUCKET_NAME AWS_S3_REGION_NAME AWS_S3_CUSTOM_DOMAIN AWS_S3_ENDPOINT_URL Bucket details if USE_S3 is set to True Optional Optional USE_DOCKER Used by APTRS Django code to validate if application deployed on Docker or Not Optional, It is already declared as True in Docker file Required to set to False USER_TIME_ZONE Used by APTRS Django code and Background task schedule time using celery Required to set the local time zon or UTC Required to set the local time zon or UTC 
     
  • List of Supported Time Zone
    •  
"},{"location":"installation/frontend/","title":"Frontend","text":"
APTRS now includes the source code of the Vite.js frontend by default, instead of a pre-built version. This change allows you greater flexibility to customize the frontend as needed. If you are deploying the application using Docker, the build process is handled automatically, so you don't need to worry about creating a production build manually.
 
However, if you choose to manually deploy APTRS, you will need to manually build the production version of the frontend and serve it using Nginx or any other reverse proxy.
 
To build the production version from the Vite.js source code, follow these steps:
 Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncd Frontend\ncp env.example .env\nnpm run build\n
 
Note
 
The .env file contains settings like the backend API domain and app environment. You can modify these as needed.
 
By default, APTRS serves both the backend and frontend on the same server, meaning they share the same IP/domain and port. The .env file uses just /api/ in docker build for the backend API domain. This setup is recommended to avoid issues with image uploads in the CKEditor within APTRS and to prevent conflicts related to Same-Origin policies.
"},{"location":"installation/frontend/#hosting-the-frontend-and-api-together","title":"Hosting the Frontend and API Together","text":"
If you wish to host the frontend on a separate domain, IP, or port from the backend API, you can configure the backend API's domain in the .env file within the Frontend folder. For example:
 Bash
nano .env\n\nVITE_APP_API_URL = http://backend-api.com/api/\nnpm run build\n
 
However, it is not recommended to host the API and frontend on separate domains, IPs, or ports. Here's why:
 
     
  1.  
    JWT Token Authentication and Cookies:
     
       
    • The API uses a combination of JWT tokens in headers and cookies for authentication and access control.
      •  
    • Cookies are domain-specific and cannot be shared across different domains unless explicitly configured with a domain-wide scope. This can lead to complexities in maintaining secure cross-domain authentication.
      •  
     
    2.  
  2.  
    Static Image Loading Issues:
     
       
    • Browsers do not allow custom headers, such as JWT tokens, for loading static resources like images.
      •  
    • APTRS addresses this by using cookies for authentication, allowing images protected by the API to be loaded by authenticated users. However, this setup is difficult to manage across separate domains, as it relies on cookies being available in the same domain scope.
      •  
     
    3.  
  3.  
    Unified Image Path Management:
     
       
    • APTRS supports storing images locally or on S3. Using the API for image access ensures consistency, as images are accessed through the same API endpoint regardless of their storage location.
      •  
    • This approach prevents exposing hardcoded S3 bucket URLs in CKEditor or frontend code. Additionally, if the S3 bucket URL changes or signed URLs expire, the API path remains consistent.
      •  
     
    4.  
  4.  
    Image Management with CKEditor:
     
       
    • APTRS manages images uploaded through CKEditor by serving them directly via the backend API, rather than using a web server. This design ensures that sensitive images, such as those used for proofs of concept (POCs), are accessible only to authenticated users. These images are protected by authentication tokens and are not publicly exposed.
      •  
    •  
      CKEditor uses <img> tags with a src attribute pointing to the API's image path. For example:
       HTML
      <img src=\"https://api.yourdomain.com/api/path/to/image.jpg\" />\n
       
      •  
     
    5.  
"},{"location":"installation/frontend/#challenges-with-hosting-the-api-and-frontend-on-separate-domains","title":"Challenges with Hosting the API and Frontend on Separate Domains","text":"
When the API is hosted on a separate domain from the frontend:
 
     
  • CKEditor hardcodes the API domain in the src attribute of the images.
    •  
  • If the API domain name, IP, or port changes, previously uploaded images will fail to load, as CKEditor cannot dynamically update the src attribute.
    •  
  • Additionally, browsers loading static resources like images do not support custom headers (e.g., JWT tokens), which can complicate access control for images requiring authentication.
    •  
"},{"location":"installation/frontend/#benefits-of-hosting-api-and-frontend-on-the-same-domain","title":"Benefits of Hosting API and Frontend on the Same Domain","text":"
If both the API and frontend are hosted on the same domain, the frontend can be built with VITE_API_URL=/api/. This approach allows CKEditor to generate image paths relative to the frontend's base domain, such as:
 HTML
     <img src=\"/api/path/to/image.jpg\" />\n
 
This configuration provides several advantages:
 
     
  • Domain Independence: The image path (/api/path/to/image.jpg) remains valid even if the domain name, IP address, or port changes, as long as the API and frontend share the same base domain.
    •  
  • Simplified Image Access: The relative path ensures that images are seamlessly accessible without hardcoding the API domain, reducing the risk of broken links if deployment configurations change.
    •  
  • Consistent User Experience: End users can load images securely without encountering authentication or cross-domain issues.
    •  
"},{"location":"installation/frontend/#recommendation","title":"Recommendation","text":"
For best results:
 
     
  1.  
    Host Both API and Frontend on the Same Domain
     
       
    • Use a reverse proxy, such as Nginx, to host both the API and frontend on the same domain.
      •  
    • Configure the frontend to use VITE_API_URL=/api/.
      •  
     
    This setup improves maintainability and ensures robustness against deployment changes, as the relative paths remain valid even if the domain name, IP, or port changes.
     
    2.  
  2.  
    Deploying Frontend and Backend on Separate Servers
     
       
    •  
      If you require separate servers for the frontend and backend (e.g., for scalability, load balancing, or easier maintenance), you can still serve both on the same domain or IP and port for users by using a reverse proxy.
       
      •  
    •  
      For example, you can deploy the frontend on one server and the backend on another, but configure your reverse proxy to route requests based on the path:
       
         
      • Requests to /api/*, media/*, static/* are proxied to the backend server.
        •  
      • Other requests (e.g., for the frontend) are served by the frontend server.
        •  
       
      •  
     
    3.  
"},{"location":"installation/install/","title":"Install","text":"
APTRS can be installed using two methods:
 
     
  • Docker (Recommended for most users)
    •  
  • Manual (User with Knowledge of Nginx and Little Python and Nodejs)
    •  
 
Note
 
APTRS does not natively support Windows installations and setting it up on Windows is not recommended. While it's possible to manually install certain components (such as the APTRS Backend, Frontend, and Database) on Windows, key dependencies like Redis require a Linux environment. Instead, you can use the Docker setup for Windows, which is the preferred option for Windows users.
 
Note
 
Default creds are sourav.kalal@aptrs.com & I-am-Weak-Password-Please-Change-Me
 
Note
 
APTRS uses cookie attributes such as Secure, HttpOnly, and Lax. For users with a Docker setup, these attributes will not have any effect. However, users with a manual setup need to ensure that they use HTTPS and that both the front end and back end are on the same domain or IP address.
"},{"location":"installation/manual/","title":"Manual Installation","text":"
If you prefer to install the APTRS without Docker and have more control over each service, such as Redis, Postgresql, Nginx, etc., or if you want to host the database on a different server, Redis on a different server, etc., you can follow the below process for deploying the APTRS on a server without Docker. 
 
The steps mentioned below were tested on the below setup:
 
     
  • OS - Ubuntu 24.10
    •  
  • Python - 3.12.7 \u00a0(3.9+ is required)
    •  
  • Python Poetry - 1.8.4
    •  
  • PostgreSQL - 16.4 (Ubuntu 16.4-1build1)
    •  
  • Redis Server - 7.0.15
    •  
  • Nginx - 1.26.0
    •  
  • NodeJS - 20.16.0 (18+ is required)
    •  
  • NPM - 9.2.0
    •  
 
Note
 
While we have provided detailed steps for manual installation and deployment, please note that this method is more prone to errors. Variations in software versions, updates, system configurations, and other factors may result in unexpected issues. Manual installation is intended for individuals who have a solid understanding of Linux, some level of development experience, or expertise in application deployment, and are comfortable troubleshooting potential errors that may arise.
"},{"location":"installation/manual/#reference-links","title":"Reference Links","text":"
     
  • Digital Ocean - How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu
    •  
  • Digital Ocean - How To Install Nginx on Ubuntu 20.04
    •  
  • Digital Ocean - How To Secure Nginx with Let's Encrypt on Ubuntu 20.04
    •  
  • Digital Ocean - How To Install and Secure Redis on Ubuntu 22.04
    •  
  • Digital Ocean - How To Install and Use PostgreSQL on Ubuntu 20.04
    •  
"},{"location":"installation/manual/#postgresql-setup","title":"PostgreSQL Setup","text":"
Run the below command to install PostgreSQL.
 Bash
sudo apt-get install \u00a0postgresql postgresql-contrib\n
 
After the installation is complete, we can access the PostgreSQL shell using the command below.
 Bash
sudo -u postgres psql\n
 
From the PostgreSQL shell, create a new database for the APTRS project. Change the name to something relevant to the project.
 Bash
CREATE DATABASE aptrsdb;\n
 
Next, create a database user for our project. Make sure to select a secure password:
 Bash
CREATE USER aptrsdb_user WITH PASSWORD 's!!D%AriPB-MO~5';\n
 
We will set the default encoding to UTF-8 and adjust other settings. Please update the time zone according to your preference, and ensure we use the same time zone as the APTRS.
 Bash
ALTER ROLE aptrsdb_user SET client_encoding TO 'utf8';\nALTER ROLE aptrsdb_user SET default_transaction_isolation TO 'read committed';\nALTER ROLE aptrsdb_user SET timezone TO 'UTC';\n\n\\c aptrsdb;\nGRANT USAGE ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO aptrsdb_user;\nALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON DATABASE aptrsdb TO aptrsdb_user;\n\\q\n
 
After completing our tasks, we ensure that the PostgreSQL service is running and set to start automatically on reboot.
 Bash
sudo systemctl start postgresql\nsudo systemctl enable postgresql\n
"},{"location":"installation/manual/#redis-setup","title":"Redis Setup","text":"
To install Redis, run the command below.
 Bash
sudo apt install redis-server\n
 
After installing Redis, we should ensure to change the supervised setting and add a password to our Redis service.
 
Bash
sudo nano /etc/redis/redis.conf\n
 \u00a0 In the redis.conf file, add the following content. Ensure to update the password to a new, secure password.
 Bash
supervised systemd\nrequirepass s!!D%AriPB-MO~5\n
 
After completing our tasks, we ensure that the Redis service is running and is set to start automatically on reboot.
 Bash
sudo systemctl restart redis\nsudo systemctl enable redis\nsudo systemctl restart redis.service\n
"},{"location":"installation/manual/#aptrs-django-apis-setup","title":"APTRS Django APIs Setup","text":"
Run the below command to install Python and other requirements for the APTRS.
 Bash
sudo apt install python3-venv python3-dev libpq-dev weasyprint\n
 
It's better to separate the API and web service from other users on the machine. It's advisable to create a separate account for it.
 Bash
sudo adduser aptrs\nsudo usermod -aG sudo aptrs\nusermod -a -G www-data aptrs\nsudo su - aptrs\n
 
APTRS uses Python Poetry to manage dependencies, so we ensure its installation.
 Bash
curl -sSL https://install.python-poetry.org | python3 -\n
 
By default, Poetry is not added to the user or system environment. Ensure you add it to the environment.
 Bash
export PATH=\"/home/aptrs/.local/bin:$PATH\"\n
 
Once completed, we can download the APTRS from GitHub, install the dependencies, and copy the example .env file.
 
Bash
cd /home/aptrs\ngit clone https://github.com/APTRS/APTRS\ncd APTRS\npoetry install\ncd APTRS\ncp env.example .env \u00a0# The .env file should be located in the same directory as the manage.py file.\n
 After obtaining the .env file from the demo environment file, ensure that you update it with the following details: the password for Redis, the PostgreSQL hostname or IP address, the Redis hostname or IP address, the secret key, and any other necessary information. It's important to review all the details in the .env file carefully. For more information on configuring the .env file and the various data it contains, please refer to the Environment Variables section.
 
Few Important details for .env file:
 
     
  •  
    WHITELIST_IP: Add the server domain name if you're using one; if using a public IP, include that as well. For local network access, add the server's internal IP to the whitelist. Specify the protocol (HTTP or HTTPS) and use Nginx instead of the Django default port (8000). You don\u2019t need to specify a port if using HTTP on 80 or HTTPS on 443. If using S3 buckets, include the bucket URL.
     
    •  
  •  
    CORS_ORIGIN: Since the frontend and backend will be on the same server, simply allow the server's public or local IP, along with the appropriate protocol and port, if necessary. Both frontend and backend should be accessible via the same domain or IP using Nginx reverse proxy. For more details, check the Frontend documentation.
     
    •  
  •  
    ALLOWED_HOST: Set this only for the server's domain name or public/internal IP, based on how APTRS will be accessed.
     
    •  
  •  
    SECRET_KEY: Make sure to update it with a secure key; the same key will be used to generate a JWT token.
     
    •  
 
From the directory where manage.py is located, run the command below.
 Bash
poetry shell\npython3 manage.py makemigrations accounts\npython3 manage.py makemigrations configapi\npython3 manage.py makemigrations customers\npython3 manage.py makemigrations project\npython3 manage.py makemigrations vulnerability\npython3 manage.py makemigrations\npython3 manage.py migrate\npython3 manage.py first_setup\nexit\n
 
Once we have completed the required setup, we need to start the server. APTRS uses Gunicorn for this purpose, which should already be installed through the steps we have completed so far. Since we are using Poetry, we need to locate the full path of Gunicorn for the APTRS project using the command below:
 Bash
$> cd /home/aptrs/APTRS\n$> poetry run which gunicorn\n\n##We might get the full path like below, this will be different for all users\n/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn\n
 
Once we have the full path for gunicorn, we can set up the gunicorn.service with the command below:
 Bash
sudo nano /etc/systemd/system/gunicorn.service\n
 
In the nano file editor, paste the following text. Ensure to update the full path for gunicorn in the gunicorn.service file.
 Bash
[Unit]\nDescription=gunicorn daemon to serve APTRS\nRequires=gunicorn.socket\nAfter=network.target\n\n[Service]\nUser=aptrs\nGroup=www-data\nWorkingDirectory=/home/aptrs/APTRS/APTRS\nExecStart=/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn --workers 3 --access-logfile - --bind unix:/run/gunicorn.sock APTRS.wsgi:application\n\n[Install]\nWantedBy=multi-user.target\n
 
We can now set up the gunicorn.socket using the command below:
 Bash
sudo nano /etc/systemd/system/gunicorn.socket\n
 Bash
[Unit]\nDescription=gunicorn socket\n\n[Socket]\nListenStream=/run/gunicorn.sock\n\n[Install]\nWantedBy=sockets.target\n
 
Now that everything is ready, we can start the Gunicorn service using the command below.
 Bash
sudo systemctl start gunicorn.socket\nsudo systemctl enable gunicorn.socket\nsudo systemctl enable gunicorn\nsudo systemctl daemon-reload\nsudo systemctl restart gunicorn\n
 
You can verify whether the APTRS APIs are operational by using the command below.
 Bash
curl --unix-socket /run/gunicorn.sock localhost/api/config/ping/\n\n{\"status\":\"ok\",\"message\":\"Server is up and running!\"}\n
 
In case of an error, you can check if the socket and service have any issues using the command below. Bash
sudo systemctl status gunicorn.socket\nsudo systemctl status gunicorn\n
"},{"location":"installation/manual/#frontend-vitejs-setup","title":"Frontend ViteJs Setup","text":"
To install Node.js, run the command below.
 Bash
sudo apt install nodejs\nsudo apt install npm\n
 
After installing NPM and Node.js, we need to create a .env file for the front end. This .env file will contain the URL for the backend Django API. Since we plan to deploy both the API and the frontend on the same server and they will be accessible through the same domain or IP address using Nginx, we will specify the backend URL as /api/. For more details, please refer to the Frontend documentation.
 Bash
cd /home/aptrs/APTRS/frontend\ncp env.example .env\nnano .env\n
 
In the Nano editor, modify the content to reflect the following changes:
 Bash
VITE_APP_API_URL = /api/\nVITE_APP_ENV = production\n
 
Now that we have configured the env file, we can install the required packages for the frontend with the command below:
 Bash
npm install\n
 
Once we have all the packages installed, we can build the frontend using the command below.
 Bash
npm run build\n
 
Once the build is completed, we can see all the front-end build at the directory below:
 Bash
cd /home/aptrs/APTRS/frontend/dist\nls \n\nandroid-chrome-192x192.png \u00a0assets \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 favicon.ico \u00a0 \u00a0 \u00a0 logo.svg \u00a0 \u00a0 \u00a0 stats.html\nandroid-chrome-512x512.png \u00a0favicon-16x16.png \u00a0hero-desktop.png \u00a0manifest.json\napple-touch-icon.png \u00a0 \u00a0 \u00a0 \u00a0favicon-32x32.png \u00a0index.html \u00a0 \u00a0 \u00a0 \u00a0robots.txt\n
"},{"location":"installation/manual/#nginx-setup","title":"Nginx Setup","text":"
We have everything set up, and our APIs are running with Gunicorn. Now, we need to configure the frontend to serve static files with Nginx and connect Gunicorn to Nginx. To get started, we first need to install Nginx using the command below:
 Bash
sudo apt install nginx\n
 
Since our frontend and backend are in the user directory, we will encounter a permission error from Nginx. To resolve this, we will grant access to the www-data user group with the command below:
 Bash
sudo chown -R aptrs:www-data /home/aptrs\n
 
To complete the setup, we can assume the domain name for our web server is demo.aptrs.com. The configuration below will have the nginx configuration files or folder names based on the domain, which users should replace with their actual domain.
 
Next, we will create a new server block in the Nginx sites-available directory using the following command:
 Bash
sudo nano /etc/nginx/sites-available/demo.aptrs.com\n
 
Paste the Below nginx configuration,
 Bash
# HTTP server configuration\nserver {\n\u00a0 \u00a0 listen 80;\n\u00a0 \u00a0 server_name demo.aptrs.com; \u00a0# Replace with your domain\n\n\u00a0 \u00a0 server_tokens off;\n\u00a0 \u00a0 client_max_body_size 100M;\n\n\n\n\u00a0 \u00a0 ### Host Validation - > Update according to your need\n\u00a0 \u00a0 if ( $host !~* ^(demo.aptrs.com)$ ) {\n\u00a0 \u00a0 \u00a0 \u00a0 return 444;\n }\n\n\u00a0 \u00a0 # Pass all /api/* to the Django backend \n\u00a0 \u00a0 location /api/ {\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_pass http://unix:/run/gunicorn.sock;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header X-Forwarded-Proto $scheme;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_set_header Host $host;\n\u00a0 \u00a0 \u00a0 \u00a0 proxy_redirect off;\n }\n\n\u00a0 \u00a0 # Home page for frontend\n\u00a0 \u00a0 location / {\n\u00a0 \u00a0 root /home/aptrs/APTRS/frontend/dist;\n\u00a0 \u00a0 index index.html index.htm;\n\u00a0 \u00a0 try_files $uri $uri/ /index.html =404;\n }\n\u00a0 \u00a0 ## Server Static from Django over nginx\n\u00a0 \u00a0 location /static/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/static/; \n }\n\n\u00a0 \u00a0 # Blocked, accessing the whole media folder may lead to access to sensitive images like POC images, \n\u00a0 \u00a0 #location /media/ {\n\u00a0 \u00a0 # \u00a0 \u00a0alias /home/aptrs/APTRS/APTRS/media/; \u00a0# Path to your media files\n\u00a0 \u00a0 #} \n\n\u00a0 \u00a0 location = /favicon.ico { \n\u00a0 \u00a0 alias /home/aptrs/APTRS/frontend/dist/favicon.ico;\n\u00a0 \u00a0 access_log off; \n\u00a0 \u00a0 log_not_found off; \n\u00a0 \u00a0 \n }\n\n\u00a0 \u00a0 ## Server user profile photo\n\u00a0 \u00a0 location /media/profile/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/profile/; \u00a0# Path to your media files\n } \n\n\u00a0 \u00a0 ## Server Company Logo Images\n\u00a0 \u00a0 location /media/company/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/company/; \u00a0# Path to your media files\n }\n\n\u00a0 \u00a0 ## HTML Report design Images like background images\n\u00a0 \u00a0 location /media/report/ {\n\u00a0 \u00a0 \u00a0 \u00a0 alias /home/aptrs/APTRS/APTRS/media/report/; \u00a0# Path to your media files\n } \n\n\u00a0 \u00a0 access_log /var/log/nginx/APTRS_access.log; \u00a0# Path to access log file\n\u00a0 \u00a0 error_log /var/log/nginx/APTRS_error.log; \u00a0 # Path to the error log file\n}\n
 
Let\u2019s enable the file by creating a link from it to the\u00a0sites-enabled\u00a0directory, which Nginx reads from during startup:
 Bash
sudo ln -s /etc/nginx/sites-available/demo.aptrs.com /etc/nginx/sites-enabled/\n
 
Let's verify if any error from the nginx with
 
Bash
sudo nginx -t\n
 If there are no errors we can start the nginx
 Bash
sudo systemctl restart nginx\n
"},{"location":"installation/manual/#https-certificate","title":"HTTPS Certificate","text":"
Once we have the domain name we can get the CA certificate with certbot using the below command. 
 Bash
sudo apt install certbot python3-certbot-nginx\nsudo certbot --nginx -d demo.aptrs.com\nsudo systemctl status certbot.timer\nsudo certbot renew --dry-run\n
"}]}
\ No newline at end of file