Safe forms
Make sure every field on the order form and the login form is checked on the server for length, format and allowed values, tighten the email check from Lesson 8.4, confirm that anything a customer types is shown as plain text everywhere, and prove it by attacking your own forms with DevTools.
Why this matters
A form is a door that lets strangers send things to your server. Most of them are customers typing their name and choosing jollof. Some are bots. A few are people poking at your site to see what happens if they type something strange.
In Lesson 7.6 you built the most important rule: the server checks every field, every time, because browser checks can be removed in ten seconds. That's already better than a lot of websites. This lesson is the review. You'll list every field and its checks, tighten the weakest one (the email address, which in Lesson 8.4 only had to "look like" an email), confirm that nothing a customer types can turn into working code on your pages or in your emails, and then attack your own form to prove it.
There's a business reason too. A form that accepts junk produces junk: orders Adjoa can't fulfil, emails that bounce, phone numbers she can't call. Good checks with friendly messages make the form easier for real customers, not harder.
In the full lesson
- The idea in plain English
- Do it
- Check it worked
- Understand what AI wrote
- Quick check
- What you can do now
The step-by-step, the prompt to copy, the video and the check-it-worked list, for every lesson in all 15 modules. GHS 399 ($40), paid once by mobile money or card, yours to keep.