Login using external provider doesn't respect returnPath parameter of login screen

[skttl]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

13.1.0

Bug summary

When loggin in using an external provider the returnPath parameter of the login screen is not respected, and the user is returned to the backoffice, instead of where the returnPath parameter describes.

This is problematic eg. when enabling basic authentication for the frontend, where the user expects to be sent to the frontend upon signing in, but instead ends up in the backoffice.

Specifics

When going to a site that has basic authentication enabled, the user gets redirected to /umbraco/login/?status=false&returnPath=%2F, notice the returnPath sitting at / for the homepage of the website.

If you log in using a regular Umbraco user from the db using a username and a password, you get redirected correctly to /.

But if you add an external login provider, eg. using the AzureSSO package, or Umbraco ID, you get redirected to the backoffice.

Steps to reproduce

Enable Basic Authentication by adding the following to your app settings

      "BasicAuth": {
        "Enabled": true,
        "RedirectToLoginPage": true,
        "SharedSecret": {
          "Value": "something"
        }
      },

Install and configure some kind of external login provider - Umbraco ID, AzureSSO or similar.

Go to your website (make sure you are not logged in to the backoffice already).

Notice you are redirected to /umbraco/login/?status=false&returnPath=%2F with the returnPath provider pointing to the url you tried to get.

Log in using the external provider

Expected result / actual result

Expected to be redirected back to the originally requested page (eg. /). Actually got redirected to the backoffice.

[github-actions]

Hi there @skttl!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Zeegaan]

Hmm I know we've seen this in v12 with this: #15259
But seems like that should be fixed, so seems like there's something else breaking this again 🙈

[skttl]

Sorry, I wrote v12 is also affected - it actually isn't, I mixed things up on that. But v13 definitely is :)

[Zeegaan]

Ah okay that makes sense, might be related to the new login screen, I'll have a look to reproduce 😁

[github-actions]

Hi @skttl,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post.

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[Zeegaan]

This also happens on 10, so it seems like its not related to the new login screen at least 😁
But I can reproduce this 👍
I've put it up for grabs for now, as we'd love some help with this 😁

[skttl]

If you can give some pointers, I can take a stab at it. Just don't know where to start :)

[Zeegaan]

I am honestly not sure myself either 🙈 Think best bet would be to see where the request ends up after authenticating via Basic auth, and then go from there 👍 I am betting it hits the backoffice controller Login action, so I think setting a breakpoint there and then stepping through would be a good starting point 😁

[shearer3000]

This doesn't seem to be an issue specific to external providers, a "normal" backoffice login doesn't seem to honor a return path either

replication steps

1. navigate to backoffice url e.g. https://localhost:31443/umbraco#/content/content/edit/1056
2. logout or allow session to expire
3. refresh page

expected: successful login navigates user to orginal url
actual: user navigated to https://localhost:31443/umbraco#/content

reported for Umbraco version 13.1.1

[jrunestone]

I've been at this issue a number of times before (#13011, #13026, #14423, #14198) and it's resurfaced again 🙄 (I'm in v13)

It's become a priority for us so I'm dedicating a bit of time for it...

The last time it was fixed we did a number on this method:

Umbraco-CMS/src/Umbraco.Web.BackOffice/Controllers/BackOfficeController.cs

Line 356 in d765e69

public ActionResult ExternalLogin(string provider, string? redirectUrl = null)

This time around, the redirectUrl passed there is always null when I login using AD. I suspect the url is getting lost in some javascript code. Some work was done in init.js here: #13026, but that code doesn't even hit anymore :)

EDIT: well something weird is going on when clicking "log in using ad":

[shearer3000]

hi - any update on this?

[jrunestone]

Hi, we've merged this PR that fixes one part of the problem (honoring the returnUrl query param if it's in the url) - the problem now is that the returnUrl query parameter isn't sent along at all.. I suspect it's some JS code somewhere that loses it but I haven't found it yet.

It's vacation time here for a couple more weeks so no work done here on my side.