Refuse a value the database cannot store, instead of quietly changing it

Wave 2 of the remediation plan. Eight findings from the feature test run were
the same defect twice: a write that reports success while storing something
other than what was sent.

The first half is a date parser that swallowed its own error. Two plugins
carried an identical private _parse_date returning None on ValueError, so an
unparseable date and a deliberately cleared one produced the same write.
PUT /api/warranty/<id> with enddate '30-06-2027' answered 200 "Warranty
updated" and stored NULL, dropping the record out of every expiry surface on
the strength of a typo; the measuring-tool calibration date did the same and
flipped the tool to 'unknown', out of the calibration report and the map
overlay. shopdb/utils/datevalues.py now holds one strict parser on the contract
surface: an explicitly empty value clears the field, anything that is not a
date is refused with a 400 naming the field, and those are different intents
with different answers. The vendor-lookup paths keep a lenient wrapper on
purpose - a provider changing its date shape must not fail the refresh of an
otherwise good record, and no person typed that value.

The second half is why the truncation findings were possible at all. MySQL was
running non-strict: sql_mode on the 5.6 server is NO_ENGINE_SUBSTITUTION with
no STRICT_TRANS_TABLES, so it accepted writes it could not store and adjusted
them. A 257-character username became its first 100 characters (and the next
distinct one then collided with it); an over-long asset number was cut at 50; a
malformed releasedate became '0000-00-00' and permanently broke every read of
that application. All with a 201. The mode is now set on the CONNECTION rather
than left to the server, so a site whose my.cnf disagrees still gets it.

That trades silent corruption for a DataError, which uncaught is a 500 - and a
500 says the server is broken when the truth is that the value does not fit. An
error handler maps it to a 400 naming the column where MySQL names one.
Verified by hand against MySQL 5.6: POST /api/users with a 257-character
username now answers 400 "That value is too long for username." and stores
nothing, where it previously stored a truncated row and answered 201.

Twelve tests. The date guard is verified by planting: restore the swallowing
parser and four of them fail. The DataError tests raise the error directly
because the suite runs on SQLite, which does not enforce VARCHAR length at all -
there is no value that would trigger it there, which is precisely why this went
unnoticed.

Scope: product
This commit is contained in:
cproudlock
2026-09-03 13:58:41 -04:00
parent aa8028f96e
commit 12392a361e
9 changed files with 419 additions and 34 deletions

View File

@@ -488,3 +488,68 @@ def test_asset_presentation_route_token():
entries = MeasuringToolsPlugin().get_asset_presentation()
entry = next(e for e in entries if e['assettype'] == 'measuring_tool')
assert entry['route'] == '/measuringtools/by-asset/{assetid}'
# --- a date that is not a date -----------------------------------------------
#
# _parse_date used to swallow the ValueError and return None, so a typo in the
# calibration date answered 200 "Measuring tool updated", stored NULL, flipped
# the tool to 'unknown', and dropped it out of the calibration report and the
# map overlay. Clearing a date and mistyping one are different intents and now
# get different answers.
def test_a_mistyped_calibration_date_is_refused_not_stored_as_null(
client, auth_headers):
created = client.post('/api/measuringtools', headers=auth_headers, json={
'assetnumber': 'MT-DATE-1',
'name': 'Date guard caliper',
'statusid': _status_id(client),
'nextcalibrationdate': '2027-01-01',
})
assert created.status_code == 201, created.get_json()
toolid = created.get_json()['data']['measuringtool']['measuringtoolid']
refused = client.put(f'/api/measuringtools/{toolid}', headers=auth_headers,
json={'nextcalibrationdate': 'not-a-date'})
assert refused.status_code == 400, refused.get_json()
assert 'nextcalibrationdate' in \
refused.get_json()['data']['error']['message']
# The stored date is untouched - the whole point of refusing.
after = client.get(f'/api/measuringtools/{toolid}',
headers=auth_headers).get_json()['data']
assert after['measuringtool']['nextcalibrationdate'] == '2027-01-01'
assert after['measuringtool']['calibrationstatus'] != 'unknown'
def test_an_explicitly_empty_calibration_date_still_clears_it(client,
auth_headers):
"""Clearing is a real intent and must keep working, or the fix above just
trades one broken behaviour for another."""
created = client.post('/api/measuringtools', headers=auth_headers, json={
'assetnumber': 'MT-DATE-2',
'name': 'Clearable caliper',
'statusid': _status_id(client),
'nextcalibrationdate': '2027-01-01',
})
toolid = created.get_json()['data']['measuringtool']['measuringtoolid']
cleared = client.put(f'/api/measuringtools/{toolid}', headers=auth_headers,
json={'nextcalibrationdate': ''})
assert cleared.status_code == 200, cleared.get_json()
after = client.get(f'/api/measuringtools/{toolid}',
headers=auth_headers).get_json()['data']
assert after['measuringtool']['nextcalibrationdate'] is None
def test_a_mistyped_date_is_refused_at_create_too(client, auth_headers):
refused = client.post('/api/measuringtools', headers=auth_headers, json={
'assetnumber': 'MT-DATE-3',
'name': 'Never created',
'statusid': _status_id(client),
'lastcalibrationdate': '01/02/2026',
})
assert refused.status_code == 400, refused.get_json()
listed = client.get('/api/measuringtools?search=MT-DATE-3',
headers=auth_headers).get_json()['data']
assert listed == [], 'nothing may be created by a refused request'

View File

@@ -108,3 +108,48 @@ def test_removing_clears_both_columns(client, db, auth_headers):
body = response.get_json()['data']
assert body['proofurl'] is None
assert body['prooffilename'] is None
# --- a date that is not a date -----------------------------------------------
#
# PUT /api/warranty/<id> with an unparseable enddate answered 200 "Warranty
# updated" and stored NULL, which drops the record out of every expiry surface
# it feeds. The local _parse_date swallowed the ValueError, so a typo and a
# deliberate clear produced the same write.
def _warranty_via_api(client, auth_headers, **fields):
payload = {'vendor': 'Acme', 'servicetag': 'WD-1', 'enddate': '2027-06-30'}
payload.update(fields)
created = client.post('/api/warranty', headers=auth_headers, json=payload)
assert created.status_code == 201, created.get_json()
return created.get_json()['data']['warrantyid']
def test_a_mistyped_end_date_is_refused_not_stored_as_null(client, db,
auth_headers):
warrantyid = _warranty_via_api(client, auth_headers)
refused = client.put(f'/api/warranty/{warrantyid}', headers=auth_headers,
json={'enddate': '30-06-2027'})
assert refused.status_code == 400, refused.get_json()
assert 'enddate' in refused.get_json()['data']['error']['message']
kept = db.session.get(Warranty, warrantyid)
assert kept.enddate is not None, 'the stored cover date must survive a typo'
assert str(kept.enddate) == '2027-06-30'
def test_an_explicitly_empty_end_date_still_clears_it(client, db, auth_headers):
warrantyid = _warranty_via_api(client, auth_headers, servicetag='WD-2')
cleared = client.put(f'/api/warranty/{warrantyid}', headers=auth_headers,
json={'enddate': ''})
assert cleared.status_code == 200, cleared.get_json()
assert db.session.get(Warranty, warrantyid).enddate is None
def test_a_mistyped_date_is_refused_at_create_too(client, db, auth_headers):
refused = client.post('/api/warranty', headers=auth_headers,
json={'vendor': 'Acme', 'servicetag': 'WD-3',
'startdate': 'yesterday'})
assert refused.status_code == 400, refused.get_json()
assert Warranty.query.filter_by(servicetag='WD-3').first() is None