|
1 | 1 | # file-relay
|
| 2 | + |
2 | 3 | Simple HTTP-based ad-hoc file relay utility with a RESTful interface
|
| 4 | +[](https://github.com/distributed-system-analysis/file-relay/actions/workflows/ci.yml) |
| 5 | +[](https://codecov.io/gh/distributed-system-analysis/file-relay) |
| 6 | + |
| 7 | +This repo provides a single-file Python script which uses the Bottle web server framework to stand up an ad-hoc |
| 8 | +web server with a simple RESTful interface for transferring files between two clients. This is of particular |
| 9 | +utility if the clients are behind separate firewalls and cannot directly connect to each other. |
| 10 | + |
| 11 | +The emphasis is on simplicity, and the expectation is that the service this program provides is transient. That |
| 12 | +is, when a user needs to transfer a file, they would start the program on a host which both clients can reach, |
| 13 | +perform the file transfer, and then shut down the service. |
| 14 | + |
| 15 | +This service is not intended to be "industrial strength", it doesn't use or require credentials for access, and |
| 16 | +it's not highly optimized. If you want those things, consider using a commercial S3 service. |
| 17 | + |
| 18 | +That said, it _is_ intended to work on a public-facing network. A modest level of security is provided by using |
| 19 | +"unguessable" values for the components of the URIs. The first is the "server ID" which is provided to the command |
| 20 | +invocation when the utility is started. If this is a sufficiently long string of arbitrary characters, it should |
| 21 | +provide all the same protections as a bearer token, meaning that only clients which know the ID will be able to |
| 22 | +access the service. Analogously, resources (i.e., files) on the service are referenced using the SHA 256 hash of |
| 23 | +their contents. This prevents collisions between uploaded files, and it means that a file can only be accessed by |
| 24 | +someone who knows that it is there (and, doing so allows the utility to confirm the file integrity on upload, and |
| 25 | +clients can do the same on download, without having to provide additional headers on the requests or responses). |
| 26 | + |
| 27 | +This utility currently offers five methods: |
| 28 | + |
| 29 | +- `PUT /<server_id>/<file_id>`: upload a file |
| 30 | +- `GET /<server_id>/<file_id>`: download a file |
| 31 | +- `DELETE /<server_id>/<file_id>`: remove an uploaded file |
| 32 | +- `GET /<server_id>`: return server status |
| 33 | +- `DELETE /<server_id>`: request server shutdown |
| 34 | + |
| 35 | +There are a number of tweaks which are expected to be added: |
| 36 | +- The hash algorithm for resource names may be changed or made configurable |
| 37 | +- The underlying web server may be changed from the reference one to Gunicorn or other |
| 38 | +- The web server should be made able to accept SSL connections |
| 39 | +- The utility needs to be packaged, either as a Python package or a container (or both) |
| 40 | +- Figure out what the server status response _should_ contain -- currently, it provides |
| 41 | +a list of the available files, which undermines the "ya gotta know it's there" story. |
| 42 | + |
0 commit comments