04 Mini projects and next steps: challenges

Consider when PHP can parse the program, when validation runs and when a service is needed.

Fix syntax in source, return useful validation for expected input errors, and report operational failure without claiming success. Inspect local logs for service failures.

Use the example config and serve only public.

Copy private/config.example.php to private/config.php, fill it locally and start with -t public. Keep filled configuration out of the shared ZIP or repository. Confirm /private/config.php is not served.

Salts are part of the stored verifier.

Use password_verify against the stored hash. The CLI creates Alex and Sam as editors and Robin as a reader. Do not store the plaintext password or pass it in the URL.

Distinguish the session cookie from server-side user_id.

The browser carries an opaque ID; the server stores user_id. Login rotates the ID before setting authenticated identity. Each protected request retrieves current account data and permissions. The local demo has no expiry strategy beyond its session lifetime behaviour.

Neither should create an authenticated session.

Both return the generic credentials message. A protected request still redirects to login. The generic message does not itself supply login rate limiting.

Check database row counts, not only the screen.

Exactly one normal submission adds a row; refreshing the resulting GET does not add another. Say “saved”, not “emailed”. This is not a guarantee against repeated simultaneous POSTs.

Browser validation can be bypassed.

Invalid input leaves the database unchanged and displays errors. Previously entered values are escaped when redisplayed. Angle brackets are plain text, not executable markup. Byte limits are the explicit server rule.

URL validation and HTML escaping solve different problems.

Reject non-HTTP(S) schemes and categories outside PHP, SQL, HTML. The valid link is stored, then escaped for HTML when displayed. A valid scheme does not guarantee content suitability.

A hidden field can be edited.

Expect 403 and no mutation. Reuse Sam’s valid token to show that CSRF and authorisation are separate checks. The SQL also targets both resource_id and owner_id.

Hiding Add is not enforcement.

Both must be rejected by the server with 403. Robin may read and search. An unauthenticated request instead redirects to login.

Record status and stored effects separately.

Missing token receives 403 without a save; GET delete receives 405 without deleting. Valid POST logout clears session and cookie; the next protected request requires sign-in.

Reuse the complete examples, then extend one requirement deliberately.

Include successful and rejected requests, expected/actual row changes, invalid URLs, other-owner IDs, missing tokens and recovery from database failure. Your write-up must name the local limitations: no public signup, password recovery, rate limiting, deliberate expiry or concurrency controls. Do not label it production-ready.