PYIC-8798: Return 400 to the user on expired IPV Session in spinner pages.

[undermad]

Proposed changes

What changed

• Added logic that return 400 to the client when IPV session expire during polling calls.

Why did it change

• Even if lambda returns 400, core-front translate it to 500 which is inaccurate and perhaps may trigger alarms.

Background:
Trust & Reuse have reported seeing a daily number of EVCS ‘get VCs’ requests using an expired access token which they reject with a 401 response (apparently it also triggers some alarms on their side). We believe the vast majority if not all of these requests are coming from the check-mobile-app-vc-receipt lambda which the frontend v2 app polling calls to check if an app VC has been received yet or not. It seems, perhaps from users abandoning the journey at the app polling pages, that calls are being made beyond the 1 hour expiry of the EVCS access token (which Orch sends us at the start of a journey).

Currently the only place we explicitly check our (IPV) session expiry (also 1 hour) is in the journey engine when transitioning between states. The actual session item in DynamoDB has a longer TTL of 24 hours.

We should add a check in the check-mobile-app-vc-receipt lambda to reject requests (with a 400 error) where the user's IPV session has expired. In turn this should drastically reduce, hopefully diminish calls to EVCS being made with an expired access token.

Issue tracking

• PYIC-8798

Checklists

• READMEs and documentation up-to-date
• Browser/ unit/ Selenium tests have been written/ updated
• No risk of exposure: PII, credentials, etc through logs/ code
• Ensure added/updated routes have CSRF protection if required

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud