Urlnao
What is Urlnao?
Urlnao is an upload service for file sharing with weechat-android.
What does it do?
Urlnao handles uploads, returns URLs and serves the uploaded files:
- A POST request is issued by a client with some file(s) to share
- Urlnao saves the uploaded file(s)
- A publicly reachable URL is then returned for each uploaded file
Example upload request using curl instead of weechat-android:
$ curl --file file=@/path/to/some/video_file.webm https://urlnao.example.com/up
https://urlnao.example.com/f/wLM1
The file will then be accessible via the returned URL.
$ xdg-open https://urlnao.example.com/f/wLM1
Example upload request using curl with multiple files:
$ curl \
--file file1=@/path/to/some/video_file.webm \
--file file2=@/path/to/some/image_file.png \
https://urlnao.example.com/up
https://urlnao.example.com/f/wLM1
https://urlnao.example.com/f/af6
Building
I recommend using Nix to build this package, but you can also just use cargo build --release
.
nix build -f . urlnao
How does it work?
Requests
All incoming requests need to be passed to Urlnao's Unix domain socket, ideally using a proxy like Nginx for handling TLS termination.
Example request with curl:
$ curl \
--file file=@/path/to/some/image_file.png \
--unix-socket /path/to/urlnao.sock \
http://localhost/up
https://urlnao.example.com/f/02f6a
Uploads
Files are uploaded by issuing POST requests to the endpoint /up
.
Every multipart request may contain more than one file,
resulting in one public URL for each uploaded file in the response.
The returned URLs are configurable and end in a randomly generated short ID, (currently) being constructed of 3 to 8 alphanumeric characters: Example:
https://u.example.com/f/02f6a
Downloads
Accessing the returned URL after a successful upload leads to a redirect, where the target location contains the original client-supplied filename:
Simplified example:
> GET https://u.example.com/f/02f6a
< 301 https://u.example.com/d/image_file.png
> GET https://u.example.com/d/image_file.png
State
A simple list of all current uploads,
including their respective checksum and filename,
is served from the /state
endpoint.
Example:
$ xdg-open https://u.example.com/state
Access Control
Access control must be implemented by the upstream proxy, allowing for any kind of authentication that both the client and proxy support.
Access to the following endpoints should be restricted to authorized users:
/up
(endpoint for uploads)/state
(endpoint listing all uploads)
Alternatively only the two endpoints:
/f
(default for--shortid-path
)/d
(default for--download-path
)
can be publicly exposed, allowing access to everything else only from a trusted network.
Developing
Development is done with the help of Nix
Development Environment
$ nix-shell
...
[nix-shell]$ cargo build --release
Integration Test
A simple integration test can be found here: nix/test.nix
To run the NixOS VM test run:
$ nix build -f . test
To run the test VM interactively run:
$ nix build -f . text.driver
$ ./result/bin/nixos-test-driver
Changelog
v0.3.0
BUG FIXES
- fixed race condition with duplicate file uploads
FEATURES / ENHANCEMENTS
- added some basic documentation
- refactored some parts
v0.2.0
BREAKING
- files are now served under
/d/<original_filename>
after a redirect from/f/<short-id>
FEATURES / ENHANCEMENTS
- each command-line parameter now includes a short description
- more elaborate information about the runtime configuration is now printed on startup
- unnecessary sub-paths following a valid request path are no longer ignored
- the new endpoint
/state/
returns a rendered list of all current uploads
v0.1.0
MVP
License
GNU Affero General Public License version 3, see LICENSE