[6.x] Redirect control panel logins to the control panel

[brandonkelly]

Description

attemptLogin backs three routes (CP login, the front-end loginPath, actions/users/login), so the CP login form's action, generated from the controller action, could resolve to a front-end route. That POST isn't a CP request, so the login redirected to the site's postLoginRedirect instead of getPostCpLoginRedirect().

 GET /cp/login → LoginController::showLogin
-  form action = action([LoginController::class, 'attemptLogin'])   # → https://example.com/logmein
+  form action = route('craft.cp.login.attempt')                    # → https://example.com/cp/login
 POST <form action> → handleSuccessfulLogin
   URL::defaultReturnUrl()
-    isCpRequest() = false → Url::siteUrl(getPostLoginRedirect())
+    isCpRequest() = true  → Url::cpUrl(getPostCpLoginRedirect())

The CP login POST route is now named craft.cp.login.attempt, and the CP login page, the login modal, and the elevated-session modal post to it. Front-end login forms are unchanged.

Evidence

• Before: LoginControllerTest › control panel logins post to the control panel and redirect to the post-CP-login redirect

  Route::post('logmein', [LoginController::class, 'attemptLogin'])   // competing front-end route
  get(cp_url('login'))->page.action
    expected 'https://localhost/admin/login'
    actual   'https://localhost/actions/users/login'               ✗
  

  After: the form posts to the CP login URL, and a form login redirects to cp_url(postCpLoginRedirect) ✓ (auth and user tests: 436 passed)

• Before: the CP login form on a site with a front-end loginPath posted to https://craft6.ddev.site/logmein, and logging in landed on the front end.
  After: it posts to https://craft6.ddev.site/cp/login.

🤖 Generated with Claude Code

[github-actions]

📚 Storybook previews

@craftcms/ui — open Storybook

No changed components detected in this Storybook.

resources/js — open Storybook

No changed components detected in this Storybook.

[github-actions]

This PR had conflicts with 6.x. Claude attempted an automatic resolution and pushed a merge commit. Please review the merge commit carefully before approving/merging.

Claude's response

The merge is committed as d7be79a and has not been pushed.

Changed: Only CHANGELOG.md had a conflict, and it was simple. Both sides had added a different "Fixed" bullet at the same spot in the 6.x notes:

• This branch added the fix for logins from the control panel's login page redirecting to the front end.
• 6.x added the fix for control panel pages and details panes shifting sideways when a scrollbar appeared ([6.x] Keep the layout from shifting when scrollbars appear #20030).

The two entries don't overlap, so I kept both, with this branch's entry first and the #20030 entry after it. I removed the conflict markers and checked that none are left in the file. Nothing was ambiguous, so I added no # CONFLICT-REVIEW: comments. No other files had conflicts, and the rest of the merge went through unchanged.

Found: Nothing else noticed.

[github-actions]

This PR had conflicts with 6.x. Claude attempted an automatic resolution and pushed a merge commit. Please review the merge commit carefully before approving/merging.

Claude's response

I've resolved the conflict and committed the merge as dab6b5b; nothing has been pushed.

CHANGELOG.md was the only conflicted file. Both sides had added a different line at the same spot in the bug-fix list: this branch added the fix for the control panel login redirecting to the front end, and 6.x added the fix for element edit pages scrolling a few pixels after a resize (#20028). These are separate entries, so I kept both, with the branch's entry first and the 6.x entry just before the existing #20030 line. Nothing was ambiguous, so I didn't add any CONFLICT-REVIEW comments.

The other changes staged by the merge came in from 6.x without conflicts, and I didn't touch them. I didn't run tests or composer ci, since the only edit was to the changelog.