From 77b3669e7bae9d447ef0c7a2f893e155a13daedd Mon Sep 17 00:00:00 2001 From: David Stone Date: Wed, 27 May 2026 17:57:01 -0600 Subject: [PATCH 1/9] fix(sso): restore front-end auto-SSO via main-site magic-link redirect MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Visiting a subsite front-end page while logged in to the main site was not re-authenticating the visitor on the subsite even in browsers that permit third-party cookies. Two interacting regressions blocked the flow: 1. #1185 turned the JSONP unattached branch in handle_broker() into an immediate '{code:0, message:"Broker not attached"}' response, which triggered sso_denied() in sso.js and set wu_sso_denied for 5 minutes on the very first subsite page-load — there was no longer any path that ever surfaced the main-site session to the broker. 2. The redirect branch still called $broker->getAttachUrl() which targets /sso-grant. After the cookie-less rework in #1084 the dispatcher in handle_requests() unconditionally appends '_grant' on main, so /sso-grant produces 'wu_sso_handle_sso_grant_grant' — an action with no listener — and the request silently 404'd on the main site, leaving the user logged out on the subsite. This change replaces both branches with a redirect to the main-site /sso endpoint that handle_server() already supports. handle_server() checks the first-party main-site auth cookie (so third-party-cookie posture is irrelevant), issues an HMAC-signed wu_sso_token via add_cookie_less_sso_token(), and 302s back to the subsite where handle_cookie_less_sso_token() consumes the token at init priority 4 and sets the broker-side auth cookie: GET /sso?_jsonp=1 -> 200 must-redirect JSONP GET /sso?return_url= -> 302 GET
/sso?sso=login&return_url= &redirect_to= -> 302 GET /?wu_sso_token= &redirect_to= -> 302 GET / -> 200, logged in For the JSONP branch (which cannot follow a 302 to HTML in a