Limit the upload requests of clients based on client URL

Tus
1

I want to block each upload requests except some of them based on their URL. For example I want to accept upload request only from http://x.com. I know that I can do it in hook “pre-create” file, but I don’t know how can I access to URL of request.

2

What technique did you have in mind to test from what URL an upload originate from? Using the Referrer header, if presented?

tusd does currently not expose details about the HTTP request (including the Referrer) to any hook. Therefore it’s not possible to this kind of check in the pre-create hook. Instead, you may want to use a proxy in front of tusd which rejects requests coming from the wrong URL.

3

I want to implement a resumable upload server to use it for my portal uploader page and a desktop application of my portal. In desktop application, I can use SSL connection and use a secret key on metadata information and check it for acceptance of the upload request only from my desktop application. using SSL connection, nobody can sniff my secret key in metadata to use for a fake page or application.
but, in my portal uploader page, I can not use metadata for my secret key and I can not reject unknown upload request. because metadata value is created in user side and it can be sniffed by user and user can make a fake upload request from unknown fake page or application with this secret key. I can only reject unknown request by check request URL.

4

Instead of restricting the URL (which is not available on desktop applications) from which uploads may start, I would recommend to use a one-time token to create uploads. Let me describe the workflow:

  1. The client uses a custom and authenticated endpoint to retrieve a one-time token.
  2. The client creates the upload containing the one-time token in the meta data.
  3. The tus server validates whether the one-time token is actually valid using the pre-create hook. If the token is invalid, the upload creation is rejected. If the token is valid, the upload creation is accepted and the token will be invalidated for reuse.
  4. The client continues the upload as usual.

The benefit is that since the server first has to create the token, you have full control over when a token will be issued or not. What do you think?

1 Like