SignedLinkEndpoint
\Benecaster\Support\SignedLinkEndpoint
Consumes the token on an emailed SignedLink and acts on it. Runs on init at priority 1, ahead of anything that might render or redirect first.
A valid account_access link SIGNS THE RECIPIENT IN. It no longer sends them to the password-reset screen. A follower who clicks the link in their welcome mail arrives on their account page already signed in, having never chosen a password — setting one becomes optional, offered on the account page.
There are three destinations, and only one of them is a failure. A subscriber-level account is signed in. An account that can edit_posts is sent to the WordPress password-reset screen instead. Both of those mean the link worked. Only the third — a redirect carrying benecaster_link_expired=1 — means it did not.
Constructor Dependencies
| Type | Description |
|---|---|
\Benecaster\Support\SignedLink |
Verifies and spends the token. |
Methods
| Method | Visibility | Since | Description |
|---|---|---|---|
maybe_handle(): void |
Public | — | The init handler. Public so unit tests can drive it without a real request. ⚠ There is no nonce check, deliberately — the signed token is the credential, and a nonce would require the session this link exists to establish. |
Constants
| Name | Value | Description |
|---|---|---|
REFUSED_ARG |
'benecaster_link_expired' |
Appended to the landing URL when a link is refused. Core prints nothing for it; the argument exists so a theme can. ⚠ The visitor arriving with it is not logged in, so do not render anything assuming a session. |
Hooks Fired
Notes
⚠⚠ **THE ELEVATED-ACCOUNT GUARD IS A FEATURE, NOT AN EDGE CASE, AND THE PAGE EXISTS PARTLY
TO SAY SO. An account that can edit_posts is never** signed in by an emailed link. It
gets the password-reset screen instead.
Why edit_posts rather than manage_options: an Editor is already enough access to be
worth protecting.
Why a reset instead of a login: an emailed link is a bearer credential — whoever opens a forwarded message is who gets in. That is an acceptable trade for a follower reaching their own feed URL and is not acceptable for wp-admin. The reset path also leaves evidence, because setting a password invalidates the old one, where a silent auto-login leaves none.
⚠ There is deliberately no filter to lift this. Do not write code assuming an administrator can arrive by link. **A podcaster testing their own follow form from an admin address will hit this and conclude the feature is broken** — which is the single most likely support question about it.
⚠⚠ Login CSRF is inherent here and is accepted, not overlooked. This endpoint logs someone in from a GET request, so an attacker who can make a victim's browser fetch a URL can sign that victim into an account the attacker controls. The damage is bounded — the victim lands on a stranger's podcast account page, not the reverse — and the alternative, an interstitial "click to continue", would reintroduce exactly the step this feature removes. **So do not add state-changing side effects to the landing page on the assumption that whoever arrives meant to.**
A refused link never says why. Expired, already spent, tampered with, and belonging to a deleted account all produce the same redirect. Distinguishing them would tell someone holding a stolen or guessed token which part of it to work on.
Telling a passwordless arrival from an ordinary login: wp_login fires for both, so it
cannot. benecaster_signed_link_logged_in fires
alongside it only for a link arrival.