`Failed to get login flow` when going back in the browser history

[natalian98]

If you log in with email and password, login ui redirects to complete the 2fa. If instead of providing it you go back in the browser and attempt to sign in again, a Failed to get login flow error will be displayed: In login ui logs:

"message":"Error when getting login flow: 403 Forbidden\n"

The solution is to 1) clear the browser cookies or 2) go again to the original url which will redirect to insert the password again (the email is cached).

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1051.

This message was autogenerated

[lukasSerelis]

Ideally this situation should not occur at all, and we could do this by providing better back-tracking ways in UI. Is there a way to give user a way back that wouldn't cause this error?

If we can not do that, we need to give a better error message in this case. Ideally not showing sign-in options at all and just showing an error screen as now it's indicating that something is wrong with inputs in the fields, whereas the real issue is that they need to clear cookies or start from the original sign in url.

So ideally the flow is either an accurate error or a button that doesn't break the UI

[nsklikas]

I am unable to reproduce this issue for some time now, can you verify that it's still happening and provide more precise instructions?

[lukasSerelis]

I am unable to reproduce this issue for some time now, can you verify that it's still happening and provide more precise instructions?

https://iam.dev.canonical.com/stg-identity-jaas-dev-grafana-k8s/login~ happening here still

[nsklikas]

This error happens on chromium, can't reproduce it on firefox.

Looks like on chromium the back does not trigger the browser to fetch the page again, this results in trying to re-use the existing flow. Whereas on firefox I think that a new flow is created.

[lukasSerelis]

Anything we can do for chromium?

[edlerd]

This is due to bfcache. It can be disabled with a header Cache-Control: "no-cache, no-store, must-revalidate", that we probably want to set on all responses of login ui.

[lukasSerelis]

This is due to bfcache. It can be disabled with a header Cache-Control: "no-cache, no-store, must-revalidate", that we probably want to set on all responses of login ui.

Would this not break the flow of Enter email address -> Click reset password -> Email saved from starting screen -> Click reset password? @nsklikas @edlerd

[edlerd]

Would this not break the flow of Enter email address -> Click reset password -> Email saved from starting screen -> Click reset password? @nsklikas @edlerd

I think not. The no cache header is only applying to html / js and not touching on cookies or url parameters. In the flow you describe we should forward the information as a parameter, the cache is not involved.

[nsklikas]

Weird thing, I can no longer reproduce this on chromium even though the image on iam.dev has not changed.

Someone who can still reproduce this error on staging, please try main so we can close this issue. Otherwise, we will deploy the latest version to staging in a few days and @lukasSerelis can try to reproduce it there and close the issue if it does not happen

[lukasSerelis]

This isn't happening anymore, can be closed