An online registration form for a junior football club
Marsascala FC registers about 320 junior players each season. Registration night is run by six volunteers with paper forms and a shared spreadsheet; last season 17 players were entered twice, one nine-year-old was allocated to the under-16 squad, and a form was accepted with the date of birth '31/02/2015'. Parents then queue at the clubhouse to pay, and the treasurer matches cash to names by hand. The club wants an online form on its WordPress site so parents can register and pay by bank transfer, with an automatic confirmation email and a page where the registrar can see who has paid. The site is on a €5-a-month shared host and currently loads over plain HTTP. The club secretary suggests adding JavaScript validation to the form and 'that will be enough'. Medical conditions are collected on the same form, and the club intends to keep the data indefinitely because former players sometimes come back.
1. Design the validation needed for the date of birth and squad fields, explaining why JavaScript validation alone is not enough.
Read the worked answer
Validation must be designed per field and must run on the server. For date of birth: reject anything that is not a real calendar date, so 31/02/2015 fails; accept one unambiguous format (ISO yyyy-mm-dd is safest); and check a plausible range, for example not before 2005 and not after today. JavaScript gives immediate feedback, but it runs in the browser and can be bypassed by disabling scripts, editing the page, or posting directly to the server, so the server must repeat every check and the database should carry constraints as a final defence. Squad allocation should not be a free choice. Derive the age band on the server from the date of birth and the season's cut-off date, then either assign the squad automatically or reject a chosen squad that does not match; that is what would have caught the nine-year-old in the under-16s. Also validate guardian email and phone, require an explicit declaration, and check that the submitted season matches the open registration window. Store the raw date of birth, not just the derived age, because age bands change each season.
2. Recommend how the club should match payments to registrations and prevent duplicate entries.
Read the worked answer
Give every registration a server-generated unique ID when it is saved, and use that ID as the payment reference. The parent pays by bank transfer quoting the reference; the treasurer downloads the bank statement as a CSV and the site matches reference to registration, marking each as paid, part-paid or unmatched, with an exceptions report for manual follow-up. This is far more reliable than matching on surname, which fails for siblings and misspellings. Duplicate prevention should be layered: a unique constraint in the database on a natural key such as lowercased guardian email plus player surname plus date of birth; a server-side check before insert with a clear 'you may already have registered' message; and an idempotency token so a double click or a refresh does not create two rows. Present probable duplicates to the registrar to merge rather than silently blocking, because twins and repeated surnames are legitimate. Card details should not be taken on the club's own site: use a hosted payment page or keep to bank transfer, so the club never stores card data.
3. Advise on the security and retention of the children's and medical data collected.
Read the worked answer
The site handles children's and health data, so plain HTTP is unacceptable. HTTPS across the whole site with a redirect, HSTS and a valid certificate is the minimum; the shared host must be assessed because cheap shared hosting often has weak isolation and ageing WordPress installations with vulnerable plugins. Keep WordPress, themes and plugins patched, remove what is unused, enforce strong passwords with multi-factor authentication on admin accounts, separate the registrar role from the editor role, and take off-site backups with tested restores. Collect only what is needed: for medical information, a yes/no flag plus a free-text note visible only to the coach and first-aider is enough; do not include it in routine exports. Retention should be explicit: registration data kept for the season plus the period needed for insurance or legal claims, then deleted or anonymised; medical notes deleted at the end of the season. The secretary's 'keep it forever' is a storage-limitation problem, not a convenience. Tell parents what is held, why, and how to ask for correction.