@tus/server: introduce middleware for access control

[Murderlon]

Access control can be done in many ways. We don't want to be opinionated on that so implementing a generic middleware function which is used before all requests seems to be the best approach.

[fenos]

One way we can implement this is to have an option on the TUS server instance ex: onTusRequest function with the following signature:

new Server({
  ...,
  onTusRequest: (request, upload) => {
      // custom logic
      throw {
        status_code: 403,
        body: "Unauthorized"
      }
  }
})

another approach could be to use a sort of pipeline pattern and chain custom handlers

async function authorizer(request, upload) {
   // custom logic
      throw {
        status_code: 403,
        body: "Unauthorized"
      }
}

function uploadPrefix(request, upload) {
   upload.addPrefix('some-prefix')
}

const server = new Server({...})

server.use(authorizer)
server.use(uploadPrefix)

server.handle(request, response)

The handler should be invoked after the Upload object is constructed since we might want to use the upload-id in order to determine the permission on that specific path

[Acconut]

I think a simple callback is sufficient here. Providing it with the current upload and HTTP request should be sufficient to give users enough information to determine the authorization. I was also wondering if it would make sense to differentiate between read (HEAD, GET requests and upload concatenation) versus write (DELETE, PATCH) access. Are there situations where you want to allow a user to have read but no write access to an upload?

[fenos]

@Acconut Yes! Absolutely - some user might have permission on GET but not on POST or DELETE

Since we have the request object passed in, I thought we could use that to determine the TUS action / method, happy to explore alternatives in case we don't want the request object to be passed in directly

[Acconut]

I thought we could use that to determine the TUS action / method

I don't think this is a sufficient approach because edge cases will likely not be covered by the users on their own. For example, if a POST request uses Upload-Concat, you also need to ensure that the end-user has read access to the uploads that get concatenated. That is something that users will easily miss and we should implement in tus-node-server. Does that make sense?

[Murderlon]

don't think this is a sufficient approach because edge cases will likely not be covered by the users on their own

I'm not sure what more we can do internally regarding differentiating read/write access together with Upload-Concat?

[Acconut]

I'm not sure what more we can do internally regarding differentiating read/write access together with Upload-Concat?

Let me explain this with a few examples:

• For a normal POST request, we must check if the user is allowed to create an upload (and validate any metadata we get with it)
• For a GET/HEAD request to upload a, we must check if the user has read access to upload a.
• For a PATCH/DELETE request to upload a, we must check if the user has write access to upload a.
• For a POST request with Upload-Concat: final;a,b, we must check if the user is allowed to create an upload and if they have read access to upload a and b.