API - image object occasionally contains a history field
Closed this issue · 0 comments
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)