search

duke-libraries / ddr-public

Public interface for Duke Digital Repository
https://repository.duke.edu
0 stars 0 forks source link

Enable curator-configured temporary access #75

Open jimtuttle opened 9 years ago

jimtuttle commented 9 years ago

A collection curator would like to provide access to an access-restricted item or items. We can expect that the requestor will negotiate the access directly with the collection curator and that the curator will use the repository interface to to select the item or items to be accessed. The repository may create a one-time URL that the curator will communicate to the requestor or perhaps create a local, non-shibboleth account that times out after a period of time or allows one-time access to the objects.

We will expect ongoing access for non-Duke users to be handled by requesting affiliate accounts, but there are use cases where the access will be single-use.

dchandekstark commented 9 years ago

I suppose the "single use link" may be the easiest solution if unauthenticated access is acceptable -- certainly easiest for the users, if not the developers. Since we have implemented omniauth, it is possible that we could permit folks to authenticate with Google, Twitter, or Facebook accounts, etc. (Currently we assume Shibboleth is the only option.) If we might want the omniauth options for other purposes, I'd be inclined to go that route -- not to say that we couldn't do both. /cc @coblej

jimtuttle commented 9 years ago

I would expect that a single-use URL would not be authenticated.

Jim

From: David Chandek-Stark notifications@github.com Sent: Tuesday, March 17, 2015 11:04 AM To: duke-libraries/ddr-public Cc: Jim Tuttle Subject: Re: [ddr-public] Enable curator-configured temporary access (#75)

I suppose the "single use link" may be the easiest solution if unauthenticated access is acceptable -- certainly easiest for the users, if not the developers. Since we have implemented omniauth, it is possible that we could permit folks to authenticate with Google, Twitter, or Facebook accounts, etc. (Currently we assume Shibboleth is the only option.) If we might want the omniauth options for other purposes, I'd be inclined to go that route -- not to say that we couldn't do both. /cc @coblejhttps://github.com/coblej

Reply to this email directly or view it on GitHubhttps://github.com/duke-libraries/ddr-public/issues/75#issuecomment-82396503.

dchandekstark commented 9 years ago

@jt112 I'd like to refine this story a bit, if possible. I would assume that the single-use link is specifically to download the content. If that's the case, then initially I would imagine it applies only to content-bearing objects, principally Components (i.e., not Items or Collections). Can we add this to our story board?

jimtuttle commented 9 years ago

What if the link points to a download set? The downloader would miss the context of the item page, I guess. Do we export a text file or files with the descriptive metadata?

I'm thinking of the workflow of the library staff member. Assuming the target content is a single component, your proposal is fine. But if there are multiple components spread over multiple items, that gets difficult.

With the export set, the staff member can select an arbitrary number of things and generate a link to those files. The downloader follows the link, maybe gets a click-through license screen, then gets the download. It would work once. Any problems would require the downloader to contact the staff member again who would go into their export sets and generate another link.

What do you think?

dchandekstark commented 9 years ago

@jt112 Seems reasonable, let's go with that story.