Open tomcrane opened 5 years ago
This recipe needs to also show how publishers provide access for machines. The spec forbids this:
Non-user-driven clients must not use access cookie services with the Clickthrough interaction pattern, and instead halt.
Use case: I don't need users to tell me who they are, but I do want them to acknowledge terms before viewing archival material.
So far so good, this is the clickthrough pattern.
Use case part 2: As a publisher I don't mind people using the clickthrough-protected images for research, data mining, natural language processing etc. Which mean they are going to write code to fetch the images. As a researcher/data scientist etc, I'm perfectly happy to adhere to the terms and conditions, but I'm going to get a machine to fetch the images directly via the API. I can easily circumvent clickthrough in a machine process (by acquiring the cookie) but I'm going against the spirit of the pattern, so I don't want to do that.
Answer - the publisher can offer an additional interaction pattern for machines to access the images. That's what external is for. I have an example of this two-fold approach in my auth playground - https://iiifauth.ch.digtest.co.uk/img/08_portmeirion.jpg/info.json.
The only problem with this approach is that it requires more work from the publisher than clickthrough does. It needs a full blown cookie service, just for the machine use case.
Clickthrough Auth interaction pattern
Use case
The material requires acceptance of terms, but the user does need to establish their identity.