Feature #13436

Add API endpoint to download master digital object

Added by Tessa Walsh over 1 year ago. Updated 7 months ago.

Status:VerifiedStart date:11/05/2020
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Digital object
Target version:Release 2.7.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

This sponsored work will add a new endpoint to the arRestApiPlugin that streams the "master" digital object for a given record given its slug (i.e. GET /api/digitalobject/:slug ).

History

#1 Updated by Tessa Walsh over 1 year ago

  • Subject changed from Add API endpoint to download master digital object from slug to Add API endpoint to download master digital object

#2 Updated by Tessa Walsh over 1 year ago

  • Target version deleted (Release 2.7.0)

#3 Updated by Tessa Walsh over 1 year ago

  • Target version set to Release 2.7.0

#4 Updated by Tessa Walsh over 1 year ago

  • Status changed from New to QA/Review

PR: https://github.com/artefactual/atom/pull/1216

This feature has been merged into qa/2.x. QA and documentation is forthcoming.

#6 Updated by Peter Van Garderen over 1 year ago

The API has been tested successfully for uploaded digital objects and externally linked digital objects (image and video).

The API also respects permission restrictions. I.e. if using an API key for a user that does not have permission to access master files, the API will return a "401 Unauthorized" response.

However, the API currently does not respect publication status. So if a user is unable to see an information object and its digital object in the UI because its publication status is set to "draft" that same user can use their API key to successfully request and download the digital object. This does mean that this user has to know the slug for this information object which is obfuscated by the fact that it hasn't been published, so how would they know the slug other than through further subterfuge? So perhaps this is a medium and not a critical security concern?

#7 Updated by Dan Gillean over 1 year ago

I would be curious to hear from Tessa about how complicated it would be to include a check for publication status, and what the consequences (e.g. performance, maintainability, etc) would be... it would certainly be better not to have to worry about inconsistent outcomes, even if the risk is fairly low (like... who is going to brute force slugs for a digital object? but still...).

#8 Updated by Tessa Walsh over 1 year ago

Thanks Peter and Dan. I don't think adding a publication status would be difficult in terms of development or maintenance, so I can implement that if you would like.

#11 Updated by Mike Cantelon over 1 year ago

  • Status changed from QA/Review to Code Review
  • Assignee deleted (Tessa Walsh)

PR to add draft checking:

https://github.com/artefactual/atom/pull/1234

I tested this PR with these authenticated user types (unauthenticated users are shut out of the REST API entirely):

           Admin  | User in no group | User in group with no draft access
Draft        Y    |        N         |                 N
Published    Y    |        N*        |                 Y

Y = can download
N = access denied

* "User in no group"'s N is due to not having "readMaster" not the draft check

#12 Updated by Mike Cantelon over 1 year ago

  • Status changed from Code Review to QA/Review

Marged PR to add draft checking.

#13 Updated by Tessa Walsh over 1 year ago

Docs have been merged to branch 2.7

#14 Updated by Dan Gillean 7 months ago

  • Status changed from QA/Review to Verified

Also available in: Atom PDF