vocdoni / saas-backend / 30345703128

63%

main: 62%

Pull #608

github

fix(members): trim whitespace in CSP login fields

The CSP login hash is a byte-exact match over the census auth fields, but
only email and birthdate were normalized. Name, surname, member number and
national ID were stored and compared verbatim, so a member imported with a
leading or trailing space could never authenticate: the voter types the
clean value, the recomputed hash differs, and the CSP answers 40029 census
participant not found.

Normalize both sides of that comparison:

- prepareOrgMember trims the four raw fields. It is the single write
  chokepoint, so this covers adding, importing and updating members.
- authFirstStep applies the same normalization to the login request, so a
  value pasted with a stray space still authenticates. Birthdates are run
  through internal.ParseBirthDate for the same reason: stored values are
  always canonical YYYY-MM-DD, while the request was compared raw.

Existing rows are repaired by scripts/trimmembers, which trims the member
fields and recomputes the login hashes of every census participant derived
from them, so published censuses keep working. It defaults to a dry run and
only writes with --apply, takes an optional --org to roll out one
organization at a time, and is idempotent. Each member is all-or-nothing:
recomputed hashes are checked against the other participants of the census
first, and a member whose trimmed hash would collide (rejected by the unique
index from migration 8) is reported for manual review instead of aborting
the run.

The repair is deliberately not a registered migration. RunMigrationsUp
tracks only the highest applied version and skips anything below it, so
writing a version into the lts ledger would silently skip any lower-numbered
migration the branch later absorbs. Keeping the backfill out of the ledger
leaves that ordering intact, and the fix is a bounded historical backfill
anyway: once the write path trims, the bad rows can no longer be created.

162 of 310 new or added lines in 4 files covered. (52.26%)

10524 of 16765 relevant lines covered (62.77%)

45.26 hits per line