[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: |
|
| 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:
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:
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. |