Look into possibly adding express-validator as middleware

[juhanikat]

This could improve some of the validation that is done in the backend, such as the URL parameter validation in the cross-search route. Currently the validation is very messy and is done in many different functions and files, which is confusing.

https://express-validator.github.io/docs/

[karilint]

Starting work on this as a narrow first step. I plan to add express-validator as backend middleware for the cross-search request shape, keeping the existing shared cross-search validator for field-level semantics. The goal is to prove the middleware pattern on the messy cross-search route without replacing unrelated validators in this task.

[karilint]

Implemented in draft PR #1163. This adds express-validator as backend middleware for cross-search request-shape validation: POST body arrays, GET route array parameters, and optional pagination numbers are checked before the route handler runs. The existing cross-search validator remains responsible for semantic validation such as filter object contents and allowed column names, so this is a narrow first middleware adoption rather than a broad validator rewrite.

[karilint]

Manual test checklist for PR #1163:

• Open the Occurrences / cross-search list and confirm rows load normally.
• Apply a normal filter such as Country = Spain and confirm results still load.
• Sort a cross-search column and confirm results still load.
• Export the cross-search CSV and confirm the download still starts.
• If testing API errors manually, send an invalid body such as columnFilters as a string to POST /crosssearch/export and confirm it returns HTTP 403 with a clear validation error.

[karilint]

Extended the implementation in draft PR #1163 beyond cross-search. It now also adds a reusable tab-list query validator middleware for the secondary list endpoints used by museum, reference, time-unit, and time-bound tabs. The existing shared parsers still normalize and enforce domain-specific details; express-validator now catches malformed query shape earlier and consistently.

[karilint]

Additional manual test checklist for the expanded scope:

• Open Museum details and confirm its Localities list loads, sorts, and paginates normally.
• Open Reference details and confirm both Localities and Species lists load, sort, and paginate normally.
• Open Time Unit details and confirm the Localities list loads, sorts, and paginates normally.
• Open Time Bound details and confirm the Time Units list loads, sorts, and paginates normally.
• Send a malformed tab-list query, for example an invalid pagination object, and confirm the API returns HTTP 400 with Invalid query parameters.