Postman
WARNING: Due to postman storing in remote servers in plaintext do not store production credentials in variables
Configuring postman for Scanning
Import the Opg Scanning collection from the opg-scanning repository opg-scanning/scripts/OPG Scanning.postman_collection.json
Add environment configuration with and set the url, lpaId and courtReference variables
E.g Environment Name: Local * url: http://localhost:8080 * lpaId: 700000003520 * courtReference: 69023357
Note: If you are using localhost then build the environment with __INSECURE_COOKIES=1 make dev-up or the xsrf token will not work
You can also run it against a development environment you have made - e.g. sfs-350.development.sirius.opg.service.justice.gov.uk
You will need to add a user to the parameter store to allow the scanner to run.
This is done in: AWS Parameter Store -> under your local environment with the suffix /local-credentials
Add a user email and a hashed password under value (you can compare against the standard dev credentials to see what format the json should be in)
When sending requests to environment deployed to AWS the environment in the url should start with a “ddc.” prefix for production-like environments and “ddc-”
- Production: http://ddc.sirius-opg.uk/
- Preproduction: https://ddc.preproduction.sirius.opg.digital/
- On demand/development: http://ddc-sw-xxxx.dev.sirius.opg.digital/
Note: The lpaId and courtReference will need to match a valid case in Sirius
Getting valid IDs
Log in to the environment you are targeting Find a case (search for Dauphin in most environments) The long ID (7000-xxxx-xxxx-xxxx) can have the hyphens stripped and be used as an lpaId The courtReference is in the upper left labeled Court Reference
Credentials
Log in credentials are in the “Log in” test body and should work on all local, developer, and feature environments
XSRF/CSRF Cross Site Request Forgery
To make requests that successfully pass a CSRF check the x-xsrf-token header needs to be set
This is done for all existing tests in the Opg Scanning collection by getting the token in the “Log in” test
var xsrfCookie = postman.getResponseCookie("XSRF-TOKEN"); postman.setEnvironmentVariable('xsrfToken', decodeURIComponent(xsrfCookie.value)); under the “Tests” tab
and setting the header in the other requests
x-xsrf-token:{{xsrfToken}}
Configuring Postman for DigiDeps and Sirius Integration
Create Sirius Dev Env and set up data
If you would like to test against your local Sirius branch then deploy your changes to dev environment Set up your data for testing by creating a client, order and assigned deputy
Create Deputy Reporting PR Env & update terraform to point at the Sirius Dev Env
- Create a new PR in the data_deputy_reporting (DDR) repo. You will need to set up the Terraform workspace so that it points at the local Terraform code of the PR branch environment and the api container for your Sirius branch
**Update the .envrc file * Locate the deputy reporting api ID from AWS API Gateway and update TF workspace (e.g. sfs247te298). The API description reads ‘API Gateway for Deputy Reporting - {api ID}’ * Update TF_VAR_image_tag with the tag from the deputy reporting PR (e.g. “v0.50.1-sfs247testbr.0”)
**Update terraform.tfvars.json * Update the accounts[“target environment”] with your Sirius branch (e.g. “SFS-247”)
**Run the following commands: * cd into infrastructure/environment * direnv allow * aws-vault exec identity – terraform init * aws-vault exec identity – terraform plan * aws-vault exec identity – terraform apply
- Run command to authenticate Postman session against the AWS endpoint - aws-vault exec identity – aws sts assume-role –role-arn {insert your operatorconfig} –role-session-name Postman
Postman setup
- Open Postman and import collection into Postman for testing - this can be found in the data deputy reporting repo titled opg-data-deputy-reporting.postman_collection.json
- Open the opg-data-deputy-reporting collection in Postman
- Update AccessKey, SecretKey and SessionToken with the results provided after running the aws-vault command above
If you would like to test the Reports Endpoint then you will need to locate a document to retrieve from the pa_uploads-branch-replication Digideps S3 Bucket and update the s3_reference in the request body. **Please note that you will need a Digideps dev or operator role to access the bucket or alternatively ask someone who does have access to the bucket * Update the POST request in Postman to point to the endpoint.
Test against environments
Testing against dev environments * If you are testing against the dev environment then add the api ID to the beginning of the url for e.g. https://sfs247te298.dev.deputy-reporting.api.opg.service.justice.gov.uk/v2/clients/{courtReference}/reports
Testing against integration * The Digideps integration env (https://integration.development.sirius.opg.service.justice.gov.uk/) is already pointing at the Sirius integration environment so no Terraform set up is required. However please bear in mind that you have less flexibility around data manipulation as other services use it for testing so please expect a specific data set. * The integration env is located on dev.deputy-reporting.api.opg.service.justice.gov.uk * You will just need to set up your case in the integration environment and run the aws-vault command to access and update your credentials for Postman * Please also make sure the url in Postman is pointing at ‘dev.deputy-reporting.api…’