Skip to content

Conversation

Joe-Edwards-GDS
Copy link
Contributor

Wider context of change

https://govukverify.atlassian.net/browse/ATO-2024

The V2 App introduces a new scenario where the app login session clashes with the original client session. In some cases (where the browser is the same) we may still be able to recover.

What’s changed

If

  • The client session in the state does not match the client session in the cookie
  • AND the client session in the state is an active client session
  • AND the client session in the state is linked to the active orch session

Then we continue processing and redirect to the RP using that client session.

N.B. this probably doesn't work as-is due to the need to go via the SPOT spinner which consumes the gs cookie.

Manual testing

TBD

Checklist

  • Successfully deployed to authdev

Related PRs

#6889

if (orchSession
.getClientSessions()
.contains(mismatchedEntity.get().getClientSessionId())) {
LOG.info("Recovering client session from state");
Copy link
Contributor Author

@Joe-Edwards-GDS Joe-Edwards-GDS Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be where we need to update the gs cookie and possibly other state to make the SPOT spinner work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we'll need to work out how the auth frontend deals with this as well on the spinner page

Copy link

sonarqubecloud bot commented Oct 7, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants