How to handle "lending" items

[glenrobson]

Transfered from: https://github.com/ArchiveLabs/iiif.archivelab.org/issues/88

Some ideas: What should we do if you request one during this first stage of not supporting lended items? 404 or 403 or generate manifest? Placeholder image? Saying … currently not supported

What if you have checked the item out?

[glenrobson]

Notes on how this works in IA:

Borrowable materials -- cookies that are set on archive.org are not set on archivelabs.org. Signing up for an account on IA creates 2 keys they call s3 keys; you can make calls to services on archive.org using those keys. You can borrow a book or access elements of a book. Once we move the IIIF endpoint to archive.org, you should have the cookies available for that book (and it should just show up in a viewer). One potential way would be to implement IIIF auth, which would take you through the borrowing process. Or we could say this type of material isn’t suitable for IIIF. 2.5M borrowable books from the IA library. Josh thinks this would be a great/elegant example and use case. Is there a way for the API to tell this is a borrow book? If you change the details term in the URL to metadata, there should be a metadata field -- the “collection” field; “inlibrary” generally means it’s borrowable (generally true & we can assume that means borrowable, although there are nuances.)

[glenrobson]

@mekarpeles thinks yes we generate a manifest and if they don’t have a cookie we through a 503 access denied.

[glenrobson]

If the viewer is on a different domain, then the cookie won't "flow through" so the previous example is not viable.

[glenrobson]

Glen suggests a 403 and a "permission denied" message is the best non-auth flow.

[glenrobson]

With message to user to login in the error html

[glenrobson]

The following is also useful context: https://github.com/ArchiveLabs/iiif.archivelab.org/issues/90

[glenrobson]

No longer relevant.