The assessment looked for three things: whether students can reach each
other's bookings, whether payment settings can be dodged, and whether the
plugin opens a way into the rest of the install. The student-isolation and
payment paths held up. These are what did not.
- The front-end login form told WordPress not to work out whether the site
was secure, so on HTTPS every student's session cookie was issued without
the Secure flag. wp_signon() only derives it from is_ssl() when the second
argument is left at its default; an explicit false reads like "no
preference" and is not.
- The update check took whatever download URL the release API returned and
handed it to core, which unpacks it over the installed plugin. The package
must now be https on git.unsupervised.ca exactly, compared on the parsed
host so a lookalike name cannot pass.
- Uninstalling dropped 2 of 14 tables and left the Stripe secret and webhook
signing key in wp_options. Removal is now a choice made in advance on
Access -> Plugin removal: records are kept unless the owner opts in (with a
typed confirmation), while credentials and the borrowed core registration
settings go every time.
- Open registration switches on the site-wide users_can_register and makes
Student the default role, arming any other signup form on the site to mint
students who could book and be billed immediately. The pending state is now
decided once, on user_register, rather than by whichever form created the
account.
- Cancel and withdraw answered "not yours" differently from "does not exist",
which let a signed-in student enumerate the studio's bookings. Both now
give the same 404.
Co-Authored-By: Claude Opus 5 <[email protected]>
KydoimosandClaude Opus 5
1847159e31