[MGNLSSO-54] Handle the case where the state is obsolete Created: 06/May/21  Updated: 01/Jun/21  Resolved: 21/May/21

Status: Closed
Project: Single Sign On
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1.1

Type: Improvement Priority: Neutral
Reporter: Maxime Michel Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2021-05-06 at 10.18.20.png     PNG File Screenshot 2021-05-11 at 11.21.02.png    
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[X]  Architecture Decision Record (ADR)

 Description   

In some scenarios:

  • either the user loaded the login page but left it idle for some time, before trying to finally login,
  • or the user has browser data for two competing instances (i.e. local & cloud)

The state parameter can become obsolete. In such a case, the user is shown with the stack trace. It would be nicer to instead show a page that prompts the user to try again.

The problem I see, however, is that Magnolia is not responsible for displaying the IDP's login form. It's impossible to simply show that page with an error label, as is commonly done. So what should we show instead?



 Comments   
Comment by Maxime Michel [ 11/May/21 ]

Update: simply waiting (30 minutes) on the Keycloak login page also leads to a warning at the login screen. But Magnolia (pac4j) still blows up after that.

Comment by Maxime Michel [ 11/May/21 ]

Waiting on the login page for 30 minutes does not result in the following error: org.pac4j.core.exception.TechnicalException: State parameter is different from the one sent in authentication request.

Comment by Maxime Michel [ 12/May/21 ]

Shorter reproduction steps:

  • start instance
  • hit login screen
  • restart instance
  • fill login info

Leads to: org.pac4j.core.exception.TechnicalException: State cannot be determined

And then (when refreshed): org.pac4j.core.exception.TechnicalException: State parameter is different from the one sent in authentication request.

All along the problem is with the SsoCallbackServlet. It has to be more tolerant to borked/invalid use cases. In case of TechnicalException, it should redirect back to the login form.

Generated at Mon Feb 12 10:50:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.