Sharing resources

[m-mohr]

It is useful to share certain resources with other users, even across back-ends. This could include process graphs, job results and web services and potentially also files.

We need to think about how to incorporate sharing. Important aspects:

• How to grant and revoke access. Examples: Dropbox, Google Docs, ...
• How to share with individual users only (by user id?) and globally.
• URLs need to be permanent (already given by using the current API URL scheme?)
• What can be shared (see list above)?
  • Sharing files could allow users to distribute illegal content, e.g. by uploading a copyrighted movie file. Restrict it to processed files only?
  • Are web services always public?
• How are shared resources billed?
  • Does external access to web services needs to be restricted after reaching certain costs?
  • Does downloading job results incur a fee? (see Does downloading job results incur a fee? #104)
  • Process graphs should be always free, I assume.

[m-mohr]

I think there are these types of sharing data:

1. Public sharing: Everybody can access the files.
2. Restricted to externals: Users provide an e-mail address and the user gets a mail with either a signed URL (not the public URL) or a password or something similar.
3. Restricted to internal users: Users provide user ids that are allowed to access the resources.
4. Not shared (default)

For 2 we would need a little more work and the URLs/password could still be passed around. 1,3,4 should be easy to add: No authentication is required for 1; 3 can be handled with the Bearer Token as usual.

We could either have a central endpoint for sharing or add sharing endpoints to all resources.

It could be implemented either as a normal REST resource:

• GET /jobs/{job_id}/shares for getting the share information
• POST /jobs/{job_id}/shares for adding a new share
• DELETE /jobs/{job_id}/shares for deleting a share

or as a list included as part of the parent resource itself:

• PATCH /jobs/{job_id}/

The content could be something like:

{
  public_access: true/false,
  users: ['someone@wwu.de', 'john_doe']
}

Externals could be identified by the @, which is not allowed to be in user_ids.

If we would like to add something like permission levels (e.g. read/write) we would need it to be a bit different:

{
  permissions: {
    '*': 'none',
    'someone@wwu.de': 'read',
    'john_doe': 'write'
  }
}

* in this case would be public access.

What would we like to be able to share?

• Jobs / Results? Sure, costs?
• Process graphs? Sure, for free.
• Files? Maybe restrict this due to people using this as file hosting?
• Web Services? Probably or are these always public?

Anyway, this is a feature that can be added easily later without breaking backward compatibility.

[m-mohr]

Maybe we need something more fine-grained regarding the costs, see #104 regarding "requester pays".

Edit: As mentioned in #104: When sharing jobs the owner can choose who needs to pay. If the requester is requested to pay, access is denied for unauthorized users. See #104 for more details.

[m-mohr]

After digging into some APIs that support sharing (e.g. Google Drive), this seems to be blowing up the API quite a lot as we would have multiple additional endpoints for each entity to share (jobs, process graphs, ...). I think I'll leave this out for now and schedule this for later. This is something that can be easily added later as a standalone feature which shouldn't break backward compatibility. There is already enough new stuff to try out and explore in v0.3.