Helpers.no API for validating volunteer workers, creating armbands and more

The API will build and run without any database, but for the worker part of the API to work (storing to database, reading etc) you need to build the database either manually or using the migration in the Business Logic Layer. Please refer to the build section for how to do this.

Build

The project should build out of the box but there are multiple dependencies that should be resolved and look into the following subsections to determine your needs based on your application usage.

Database for registering and storing volunteers

First, unless you are migrating an existing database, you can either create your own database mbased on the models or you can simply apply the migrations. To do that navigate to to the BL folder cd Source/Helpers.BL Run the following command: dotnet ef database update You might need to remove the constructor in the HelperContext.cs (add it after applying the migrations so that the DI layer works in the API)

This should create the database and to access it you need to change the connection string in the Helpers.API appsettings.json file and the OnConfiguring method in the context

Enabling Oauth2, OpenID or other certified authentication and authorization services

Annotate the different API commands in the controllers with either, both or [Authorize] [Authenticate] depending on your needs If you wish to self-host OpenIdDict there is a "Add OpenIdDIct" method in the custom service collections, that when enabled adds a middleware to the https pipeline(s) which allows for automatic token handling depending on the selected flow

Google drive integration

Create a new file named driveCredentials.json with the exact same template as the driveCredentialsTemplate.json i.e.

{
"type": "",
"project_id": "",
"private_key_id": "",
"private_key": "",
"client_email": "",
"client_id": "",
"auth_uri": "",
"token_uri": "",
"auth_provider_x509_cert_url": "",
"client_x509_cert_url": "",
"drive_folder": ""
}

Populated with your own data. When new armbands are subsequently created, the armbands will be uploaded to the folder denoted by its <google_id> in the driver folder property

Azure hosting if changing host

If you wish to autohost on commits, you can change the workflow in this repostitory, namely the GithubAction workflow named: ".github/workflows/azure-deploy.yml"

Creating armbands

There are two methods of creating armband for the application, the foremost and simplest method is to simply execute the main.py script location in wwwroot/python in the following manner:

python3 main.py <seed> <number_of_armbands_> 

or run the application

python3 main.py

to view the application usage

Or you can edit your python_path in the command: FetchQrCodesFromPython and run it through the API.

Code structure

The code can be found in the Source folder and some projects can be safely ignored:
Helpers.TestingProject -> Project for testing the word and authentication functionality
Helpers.Openiddict -> Openiddict server for local authentication and authorization. This can be enabled on the API in the projectservicecollection
Helpers.SPA -> Earlier version of the FE
Helpers.API -> API for the workers and QR endpoints. For development it generates a Swagger frontend for the OpenAPI implementation for the QR functionality. In the API folder you can find a python subfolder containing the actual QR-gen code. The API are using CQRS pattern so the controller cocmmand implementation can be found under /commands/