Invalid checks/redirects in UI

[nsklikas]

Not sure if this is what causes the bug or not, but in mulitple places in the frontend we are checking if the response from the backend contains a request_url (and sometimes we even redirect the user there), eg try to go to https://iam.dev.canonical.com/stg-identity-jaas-dev-login-ui/ui/reset_password. I thought we caught those on review, but it looks like some of these changes went through.

From a quick search:

• identity-platform-login-ui/ui/pages/reset_password.tsx

  Line 54 in 2357551

  if (data.request_url !== undefined) {

• identity-platform-login-ui/ui/pages/reset_email.tsx

  Line 40 in 2357551

  if (data.request_url !== undefined) {

• identity-platform-login-ui/ui/pages/setup_secure.tsx

  Line 50 in 2357551

  if (data.request_url !== undefined) {

• identity-platform-login-ui/ui/pages/setup_passkey.tsx

  Line 46 in 2357551

  if (data.request_url !== undefined) {

• identity-platform-login-ui/ui/pages/setup_backup_codes.tsx

  Line 46 in 2357551

  if (data.request_url !== undefined) {

I am pretty sure that this is not correct, but I am not sure what these checks are trying to accomplish. In a production environment all these are pointing to admin APIs, which are not exposed to the public internet. The request_url is the URL that the backend used to call Kratos, there is no reason to call the same URL from the frontend.

Originally posted by @nsklikas in #247 (comment)

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

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

This message was autogenerated

[edlerd]

We never redirect to the data.request_url, the value is only checked. We redirect to the current page while setting the current flow ID in case the data.request_url is defined on the flow object. Basically reloading the current page with the current flow.

I don't think that is a bug per se. I don't know why we would refresh in case the data.request_url is set. Do you have insights why this value might be present @nsklikas ? Which conditions lead to it being populated, and why would we want to refresh in case it is?

[nsklikas]

Well, the browser is redirected to request_url at

identity-platform-login-ui/ui/pages/reset_password.tsx

Line 55 in 2357551

window.location.href = data.request_url;

.

I believe that this field will always be populated. AFAICT It is the url that was used to make this request,

The kratos api docs say that it is a required field in the response:

RequestURL is the initial URL that was requested from Ory Kratos. It can be used to forward information contained in the URL's path or query for example.

I don't think that is a bug per se. I don't know why we would refresh in case the data.request_url is set. Do you have insights why this value might be present @nsklikas ? Which conditions lead to it being populated, and why would we want to refresh in case it is?

I don't know, I was not involved in this and that's why I was hesitant to remove it. Perhaps @natalian98 has some insight

[edlerd]

Well, the browser is redirected to request_url at

identity-platform-login-ui/ui/pages/reset_password.tsx

Line 55 in 2357551

window.location.href = data.request_url;

.
I believe that this field will always be populated. AFAICT It is the url that was used to make this request,

Right, that seems incorrect. I just tested and could not see any difference when removing those checks for the request url. So putting up a PR to remove them.