Torino is a files storage explorer created by Roberto Prevato, consisting of:

• a back-end API that provides the necessary features to handle storage containers and a virtual file system
• a front-end SPA that provides an administrative interface to configure containers, upload files, navigate through the virtual file system

Using this project is possible to provision a private files explorer using Azure Storage Account, in a few minutes. ✨ 🍰

Torino provides two working modes: Express and Normal.

The project is a work-in-progress and by no mean complete. However, Torino is ready for use and provides complex features:

• Ability to run the application in a Docker container, requiring only a Storage Account (Express mode)
• A single page application front-end built using modern technologies: TypeScript, HTML5, SASS, React; offering folders view, a photo gallery implemented with PhotoSwipe, features to display pictures, play MP3s and videos
• A clean API offering OpenAPI Documentation and supporting OpenID Connect
• CI/CD automation using GitHub Workflows, reusable workflows and a branch strategy to handle multiple environments
• Bicep templates to provision the required Azure services, with automated deployments
• Access management using JWT Bearer authentication (tokens issued by Azure Active Directory)
• Safe handling of private files: access to files is controlled using temporary shared access signatures for the Azure Blob Service
• Resizing of pictures, supporting common pictures formats
• Logs collected using Application Insights, including detailed informations about dependencies, like queries made by SQLAlchemy
• Database migrations handled using Alembic, and ORM provided by SQLAlchemy (uses code-first and has built-in support for PostgreSQL and SQLite)
• As alternative to the SQL relational dbs mentioned above, it can be configured to use the Table API of the same Storage Account that is used for blobs

Since the project is open source and includes automation, it can be easily modified and enhanced with the desided features.

The fastest way to try Torino is using the provided Docker image:

docker run -p 8080:80 \
  -e APP_STORAGE_ACCOUNT_NAME="<NAME>" \
  -e APP_STORAGE_ACCOUNT_KEY="<KEY>" \
  robertoprevato/torino

This requires using an existing Storage Account, which must enable CORS (either from all origins, or the specific origin used when starting the container). Important CORS must be enabled for the Blob Service, under Settings > Resource sharing (CORS).

The system in Express mode runs without users' authentication, and can be used immediately to start creating containers and uploading files to the storage. By default all information is stored in the provided Storage Account (Table and Blob services).

To include the integration with an Azure Application Insights service, use the following environmental variable:

-e APP_MONITORING_KEY="<INSTRUMENTATION_KEY>"

To use a SQLite database within the container itself, instead of the Azure Storage Table API, add the following variable:

-e APP_DB_CONNECTION_STRING="sqlite+aiosqlite:///torino.db"

For more information about running the system this way, refer to the dedicated Wiki page.

Using the system in Normal mode provides the full set of features implemented in the system, but it requires going through several configuration steps, for the first-time setup.

The following instructions provide an overview of the necessary steps to use all the features provided in this repository.

1. Fork this project
2. GitHub reusable workflows require paths to a specific organization, therefore update the provided .github/workflows/infrastructure.yml and .github/workflows/server.yml to point to your account's name; update the uses property of the deployment stages:

  deploy-dev:
    needs: build-app
    if: github.ref == 'refs/heads/dev'
    uses: <ACCOUNT or ORG>/<PROJECT>/.github/workflows/server-env.yml@dev

3. Choose a project name, for example if you chose pincopallo, update the workflow files to use pincopallo instead of torino (note that a bug in the GH reusable workflows doesn't allow to use dynamic input from env variables for called workflows, therefore it is necessary to write more than once the project name ref. 1, ref. 2)

4. Create Azure credentials to enable automated deployments from GitHub Workflows, refer to this documentation for more information:
   Deploy to App Service using GitHub Actions

5. Create the necessary app registrations in Azure Active Directory. The folder infrastructure/apps contains an example bash script that can be used to create the app registrations for the API and the SPA, including application roles handled by the system. Once the applications are created:

   • Configure the API app registration to expose an api, and the SPA app registration to use that API
   • Refer to this documentation for more information on how to expose an API:
     • Quickstart: Configure an application to expose a web API
     • Quickstart: Configure a client application to access a web API
   • API scope and SPA client ID must be configured in the SPA's settings.js under ui folder
   • Configure the API client ID and audience in the YAML settings of the web service, under server folder
     • Note: it is possible to use several settings.$APP_ENV.yaml files, the right file is read when the application starts depending on the following env variable: APP_ENV

# EXAMPLE
auth:
  audience: api://e9ee7140-519d-458c-9621-0b3e110ea5a3
  issuer: https://sts.windows.net/b62b317a-19c2-40c0-8650-2d9672324ac4/

6. Configure GitHub secrets like described in Configuring GitHub Actions

7. Once secrets are configured in GitHub, it is possible to run the infrastructure pipeline, to provision the dev environment of the system. This workflow is configured to be run manually (workflow_dispatch).

8. Once the Azure services are created for an environment (e.g. dev-example-rg), it is possible to create a GitHub release referencing the dev branch to trigger a deployment of the web application in the resource group. In the provided configuration, the SPA is served by the same web application that offers the API, this can be modified as desired.

Torino supports the following persistence layers for the virtual file system (virtual folders tree and file nodes):