Add support for 403 subrequests to user.login route

We've hit this in the first Drupal CMS template, just realised I should check whether it's a gin_login issue :)

Is this the same (or similar) issue as #3547364: Stylesheet missing on /user/register when 403? The steps to reproduce sound quite different, but maybe the MR I wrote there would work to solve this issue too? Please check! Thanks.

I just tested on Gin Login 2.1.x branch with a clean standard Drupal 11 install (via ddev-drupal-contrib), but was unable to reproduce the issue. I also sanity checked same behavior on MR 48 for aforementioned issue #3547364, and saw no adverse impact.

Maybe this is something specific to do with Drupal CMS?

I'm attaching some screenshots as evidence that it works as designed with a clean standard Drupal 11 install:

✅ 403 page left empty

✅ 403 page set to /user/login

Hi, Tested this on Drupal 11.2.3 with the Gin theme and Gin login enabled and /user/login set as the 403 page. As mentioned in the @wilson3 comment, after testing, the issue could not be reproduced — the login form rendered correctly and no broken layout was observed.

Could you provide more detailed steps to reproduce the issue?

FWIW the original report is not about Drupal CMS :)

I believe the screenshot in #4 actually does show the problem, compare side by side with the form at /user? The fields are weirdly indented and the page title is squished.

Here is what it looks like in Drupal CMS, it is more obvious because of theme differences.

Does not appear to be the same as #3547364: Stylesheet missing on /user/register when 403. As noted in the OP, the issue is that the front end theme is loaded rather than the admin theme.

Thanks for clarifications. So this is not the same issue as #3547364: Stylesheet missing on /user/register when 403, but its in the same vein and the fix there would likely be influenced in some way by a fix for this issue.

I was able to take a look at this and unfortunately the other issue doesn't help with this one. Our problem is in ThemeNegotiator, when the route match happens in negotiateRoute to determine whether to swap the theme, the match fails because it uses the original request route. Somewhere along the line the route changes to match user.login so that's why everything else happens as expected later on, it just loads with the wrong theme.

Found a way to determine the route of the sub-request, this should resolve all similar issues.

Manually tested !52 against vanilla core (11.3.x-dev). It didn't seem to work. What I did:

1. Installed clean; drush si -y && drush -y en gin_login, with !52 checked out
2. Logged in as admin and set /user/login as the 403 page
3. Logged out and tried to visit /admin/structure

It yielded this:

That looks Claro-ey, but not Gin-ey.

Never mind, I'm wrong! I had forgotten to set my admin theme to Gin. When I do that, it works fine!

This is a Drupal CMS release target because it will let us remove a couple of annoying workarounds.

Thanks everyone, glad we got this sorted.