Skip to content

Address Credential Issuer frontend

License

Notifications You must be signed in to change notification settings

govuk-one-login/ipv-cri-address-front

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ipv-cri-address-front

GitHub Action: Scan repository Coverage

Frontend for the Address Credential Issuer.

This is the home for the front end user interface for a credential issuer as a part of the Identity Proofing and Verification (IPV) system within the GDS GOV.UK One Login service. Other repositories are used for core services or other credential issuers.

Installation

Clone this repository and then run

yarn install

Precommit Hooks

Install pre-commit from here

Run pre-commit install to install pre-commit hooks locally.

If you get the error:

[ERROR] Cowardly refusing to install hooks with `core.hooksPath` set.

Run git config --unset-all core.hooksPath to reset your git hook settings.

Environment Variables

  • BASE_URL: Externally accessible base url of the webserver. Used to generate the callback url as part of credential issuer oauth flows
  • PORT - Default port to run webserver on. (Default to 5010)
  • GA4_ENABLED - Feature flag to disable GA4, defaulted to false
  • UA_ENABLED - Feature flag to disable UA, defaulted to false
  • UA_CONTAINER_ID - Container ID for Universal Analytics, required for UA to work correctly. Default value is GTM-TK92W68
  • GA4_CONTAINER_ID - Container ID for GA4, required for analytics to work correctly. Default value is GTM-KD86CMZ
  • ANALYTICS_COOKIE_DOMAIN - Cookie domain to persist values throughout the different sections of the OneLogin journey. Default value is localhost
  • LANGUAGE_TOGGLE_DISABLED - Feature flag to disable Language Toggle, defaulted to true

Testing

Mock Data

Wiremock has been used to create a stateful mock of the API, through the use of scenarios. These configuration files are stored as JSON files in the ./test/mocks/mappings directory.

This can be run by using:

yarn run mocks

The frontend can be configured to use this server through changing two environment variables:

  • NODE_ENV = development - this enables a middleware that passes the x-scenario-id header from web requests through to the API.
  • API_BASE_URL = http://localhost:8010 - this points the frontend to the wiremock instance.

A browser extension that can modify headers can be used to set the value of the header in a web browser. Example - Mod Header

Request properties

In order to support consistent use of headers for API requests. middleware is applied to add an instance of axios on each reqest onto req.axios. This is then reused in any code that uses the API.

Testing Environment Variables

Running against a deployed system

Variable Value Comment
CREDENTIAL_ISSUER_LABEL Address CRI Dev There might be many different buttons on the credential issuer page, this allows selection of a single one
CORE_STUB_URL https://di-ipv-core-stub.london.cloudapps.digital/ Initial host to start the web journey on. Will be either Core or a Core stub.
MOCK_API false Should the automatic mocking be used

Browser tests.

Browser based tests can be run against the mock server, and should be able to be run against an instance of the API.

These tests are written using Cucumber as the test runner and Playwright as the automation tool. They also follow the Page Object Model for separation of concerns.

They can be run using:

./test/brower $ cucumber-js

Using mocked scenario data

Any cucumber feature or scenario with a tag prefixed with @mock-api:

eg:

  @mock-api:address-error
  Scenario: Address error
  ...

This scenario will be configured to send a x-scenario-id header of address-error on every web browser request.

Using live data

Most scenarios will not be able to run against a live system. These include journey flows involving errors. The few scenarios that can be run against both live and mocked data should be tagged with "@live" to make it clear they can be run against live.

These should be able to be run using cucumber-js as below:

./test/browser $ cucumber-js --tags "@live"

Running browser tests in isolation

You can run browser tests in isolation by decorating the scenario with a @only tag and then running yarn run test:browser:ci:only.

eg:

  @only
  Scenario: Address error
  ...

Code Owners

This repo has a CODEOWNERS file in the root and is configured to require PRs to reviewed by Code Owners.