New MPC written in Typescript. Digital service for allocating, managing and handing over POM cases. UI repository.
The template project is set up to run with two sets of credentials, each one support a different oauth2 flows. These need to be requested from the auth team by filling in this template and raising on their slack channel.
These are used to allow authenticated users to access the application. After the user is redirected from auth back to the application, the typescript app will use the returned auth code to request a JWT token for that user containing the user's roles. The JWT token will be verified and then stored in the user's session.
These credentials are configured using the following env variables:
- AUTH_CODE_CLIENT_ID
- AUTH_CODE_CLIENT_SECRET
These are used by the application to request tokens to make calls to APIs. These are system accounts that will have their own sets of roles.
Most API calls that occur as part of the request/response cycle will be on behalf of a user. To make a call on behalf of a user, a username should be passed when requesting a system token. The username will then become part of the JWT and can be used downstream for auditing purposes.
These tokens are cached until expiration.
These credentials are configured using the following env variables:
- CLIENT_CREDS_CLIENT_ID
- CLIENT_CREDS_CLIENT_SECRET
To allow authenticated users to access your application you need to point it to a running instance of hmpps-auth
.
By default the application is configured to run against an instance running in docker that can be started
via docker-compose
.
NB: It's common for developers to run against the instance of auth running in the development/T3 environment for local development. Most APIs don't have images with cached data that you can run with docker: setting up realistic stubbed data in sync across a variety of services is very difficult.
When deployed to an environment with multiple pods we run applications with an instance of REDIS/Elasticache to provide a distributed cache of sessions. The template app is, by default, configured not to use REDIS when running locally.
The easiest way to run the app is to use docker compose to create the service and all dependencies.
docker compose pull
docker compose up
To start the main services excluding the example typescript template app:
docker compose up --scale=app=0
Create an environment file by copying .env.example
-> .env
Environment variables set in here will be available when running start:dev
Install dependencies using npm install
, ensuring you are using node v20
Note: Using nvm
(or fnm), run nvm install --latest-npm
within the repository folder
to use the correct version of node, and the latest version of npm. This matches the engines
config in package.json
and the github pipeline build config.
And then, to build the assets and start the app with esbuild:
npm run start:dev
Once the application is running you should then be able to login with:
username: AUTH_USER password: password123456
To request specific users and roles then raise a PR to update the seed data for the in-memory DB used by Auth
npm run lint
runseslint
.npm run typecheck
runs the TypeScript compilertsc
.
npm run test
For local running, start a wiremock instance by:
docker compose -f docker-compose-test.yml up
Then run the server in test mode by:
npm run start-feature
(or npm run start-feature:dev
to run with auto-restart on changes)
And then either, run tests in headless mode with:
npm run int-test
Or run tests with the cypress UI:
npm run int-test-ui