API - image object occasionally contains a history field

[fozcode]

There is a scenario whereby an API call to /api/v1/details/ or /api/v1/list/ can return a history field in the image object(s). For example:

(qis) qurumatt:qis matt$ curl 'http://localhost:5000/api/v1/details/?src=Mixed/matt-new.tif'
    ...
    "height": 374,
    "history": [
      {
        "action": 1,
        "action_info": "File detected: Mixed/matt-new.tif",
        "action_time": "2018-10-16T15:51:49.579022Z",
        "id": 246,
        "image_id": 146,
        "user": null,
        "user_id": null
      }
    ],
    "id": 146,
    ...

Whereas if you make the same call a second time (and subsequently), there is correctly no history field:

(qis) qurumatt:qis matt$ curl 'http://localhost:5000/api/v1/details/?src=Mixed/matt-new.tif'
    ...
    "height": 374,
    "id": 146,
    ...

This bug is due to the caching of image objects in the SQLAlchemy session. For image files that the application finds on disk for the first time, a new audit trail is saved against the image and the image object is returned from the SQLAlchemy session cache. For images that already existed, the audit trail remains unloaded because it is lazy-loaded and is neither accessed nor changed.

This needs fixing to remove the history field (a) because it makes the return values inconsistent and (b) because it could in theory lead to user details being publicly visible in the same way as #13.

The bug affects APIs that deal with new files on disk (or the discovery of them). This is details, list and upload, though purely by chance the bug does not arise for upload because the internal implementation uses a separate SQLAlchemy session.

• [ ] Write new tests
• [ ] Fix for details
• [ ] Fix for list
• [ ] Fix for upload (in case of internal implementation changes in future)