TUSd Server Implementation - Golang Developer

Golang TUSd Resumable Upload Application and Server Deployment This document outlines the requirements for the implementation resumable upload server using the TUS protocol. The server must use the TUSd server (built in Golang) which will require the development of a Golang application to implement resumable uploads from our Wordpress website. The following documentation details the TUSd server library: [login to view URL] The server will be based on a new Ubuntu DigitalOcean VM provided on project start. SSH access will be provided before the project commences. We are using the [login to view URL] client deployed on a Wordpress website, which will be used by the server. This has already been configured and there should be no need to make changes to this as part of the project. A public url will be provided to the developer for testing purposes. The TUS server will need to: 1. Authenticate with a simple API. --------------------------------- The Uppy client is configured to pass an invite code to the upload server via metadata ([login to view URL]). meta: { inviteCode: ‘123-123-123’ } The TUSd application must make a GET request to our API before proceeding with any uploads GET [API URL]/invite/[inviteCode] The API will return a JSON object as follows: RESPONSE (on success) { "inviteCode": "XXX-XXX-XXX", "accessCodeId": "123", "dateCreated": "2019-01-01 16:43:22", "name": "xxxxx", "email": "xxxxx@xxxxxx", "accessCode": "YYY-YYY-YYY", "activated": "1", "eventName": "123", "eventDate": "2022-04-09 15:28:37", "path": "relative/path/to/upload", } Within the response, the path specifies where the TUSd application should store each file within the upload session. In the event that an invite code is not found or is no longer valid (a process which we will manage externally), the following response would be returned and file uploads should be denied. RESPONSE (on error) { "inviteCode": null, "accessCodeId": null, "dateCreated": null, "name": null, "email": null, "accessCode": null, "activated": null, "eventName": null, "eventDate": null "path": null } The TUSd application will therefore need to verify that the data received from the API is a success response by checking that path is not null. Note: For now all additional fields will not be required. Note: From reviewing the TUSd documentation, it is recommended that the API request can be accomplished by using an HTTP hook as outlined in the following documentation: [login to view URL] 2. Store files locally in a specified folder structure. ------------------------------------------------------- The Ubuntu server will be configured with a block storage volume mounted as a separate drive. The TUSd application will need to be configured to store all files on this drive, then use the relative path provided in point 1 to determine the location of each file. Note: By default TUSd stores all files using a GUID for the filename and a .bin extension. A separate .info file accompanies each uploaded file containing information about the originating file name, file extension, mime type etc. -rw-r--r-- 1 root root 2702083 Apr 11 15:56 [login to view URL] -rw-r--r-- 1 root root 321 Apr 11 15:55 [login to view URL] -rw-r--r-- 1 root root 1353446 Apr 11 15:49 [login to view URL] -rw-r--r-- 1 root root 321 Apr 11 15:49 [login to view URL] -rw-r--r-- 1 root root 2584571 Apr 11 16:32 [login to view URL] -rw-r--r-- 1 root root 321 Apr 11 16:32 [login to view URL] -rw-r--r-- 1 root root 713280 Apr 11 15:49 [login to view URL] -rw-r--r-- 1 root root 320 Apr 11 15:49 [login to view URL] Below is an example a .info file: {"ID":"0a0774f8e3a2c7d87ba41f956b8c86be","Size":2584571,"SizeIsDeferred":false,"Offset":0,"MetaData":{"filename":"[login to view URL]","filetype":"image/jpeg","name":"[login to view URL]","type":"image/jpeg"},"IsPartial":false,"IsFinal":false,"PartialUploads":null} After a file has been successfully uploaded, the TUSd application should move files to the path defined by the API and be renamed to their original file name. Example: [drive]/data/[login to view URL] Should be moved to: [drive]/data/[path]/[login to view URL] 3. Install apache, setup an SSL and configure a reverse proxy to handle HTTPS connections. ------------------------------------------------------------------------------------------ The Uppy client will be hosted over HTTPS however the TUSd client does not natively support this. Uppy will therefore return a mixed content error when uploading files directly to the TUS server. It is required that a reverse proxy be set up on the Ubuntu server, details and sample configuration scripts can be found below. [login to view URL] Note: The Ubuntu server will not be pre-configured with apache so this will need to be installed. We will set up an entry in our DNS to point upload.[our domain name] to the server which can then be used for the SSL. The server should use LetsEncrypt for SSL certificates and be configured to auto renew SSLs. Full instruction for this are provided below: [login to view URL] 4. The TUSd application must be configured to run as a service -------------------------------------------------------------- The TUSd application must be configured to launch automatically whenever the server is restarted. Instructions to perform a manual restart of the TUSd application over ssh should also be provided upon completion of the project. Optional: Please advise if the TUSd application can automatically restarted in the event of a crash and implement this feature. This feature would be deemed as a non-critical requirement for the project. 5. Concurrent uploads. ---------------------- The Uppy client is configured to allow up to 100 uploads per session, with 6 files being uploaded concurrently per upload session. Each file being up to 4Gb in size. As part of our acceptance testing, we require that the server be able to handle 6 or more Uppy sessions at the same time. This would equate to 36 concurrent uploads with no upload fails reported by Uppy.. We're looking to establish an ongoing relationship with a developer to set up and support the server moving forwards, so whilst the scope of the initial piece of work is to configure the server to meet the requirements above, we'd be looking to work on an ad-hoc basis to support the running of the server and make further improvements and security enhancements. Please provide a quote for the initial project and options for an ongoing support agreement if this is available.