Returns version information about server application.

Return basic information for setting up a web client.

Authenticate with account name and password.

If successful, an authentication token is returned that can be used for subsequent calls to protected routes.

The id must be a configured OAuth provider. This requests will redirect the client to the configured provider. After authentication there, the provider will redirect back to sharry.

This only works, if sharry uses TLS (https), and the correct callback-url is configured at the provider.

This endpoint is for OAuth2 providers when delegating control back to sharry. At this stage, sharry will do basic validation and then finishes logging into the application.

When using an authenticating proxy in front, this login route can be used to rely on trusted request headers to perform login.

Authenticate with a token. This can be used to get a new authentication token based on another valid one.

This route informs the server about a logout. This is not strictly necessary.

Create a new account.

When signup mode is set to "invite", sharry requires an invitation key when signing up. These keys can be created here. Creating such keys requires an admin user. It also asks for a password that must be set in the configuration file.

Lists all available (internal and external) accounts. An optional query parameter can be used to narrow the list down by username. It is a simple substring search in the username property.

Creates a new account. The account is marked as internal and the provided password is used when authenticating. Sharry supports external authentication, these accounts however, cannot be directly created. They are created on demand.

The username and password properties are mandatory. The others are optional or have a sensible default.

Returns details about the account with the given id. Note that the id is not the username, but the account-id.

Modifies an existing account. It is only possible to modify state, email and the admin property.

If the email property is not supplied, an existing email is removed from the account.

The password can be changed for an account. If it is null or empty, it is left unchanged. Also, if the account is not internal, a given password is ignored.

Deletes the account and all its related data.

Allows the current user to get their e-mail address.

Allows the current user to change their e-mail address.

Allows the current user to remove their e-mail address.

Returns wether the current account is available for a password change. If this returns false, the POST request to this url will always fail.

Allows users to change their password. This is only valid for internal accounts.

Lists all aliases of the current user.

Create a new alias. The id is generated to some random string if not specified, such that the URLs resulting from this alias are not guessable.

Returns details about an alias for the given id.

Change some properties of an existing alias.

The id is optional; if it is not specified a new random one will be generated.

Deletes an alias.

Gets a list of accounts suitable for adding them as members to an alias.

Returns a list of all shares of the current user.

Returns all details about a share.

Allows to delete a share and all associated files.

Sets the name of the share.

A name is optional and can be removed via this route.

Sets the validity property of the share to a new value.

Sets the description of share.

Sets the maximum downloads property.

Sets or changes the password of the share. If the share already has a password defined, it must be given with the request. Otherwise it may be empty.

Removes the password that has been set for this share. If this share has no password set, a successful response is sent.

A share can be published. That means it is accessible by everyone (no access protection!) using a different url and id. This link can then be shared. Once the validity time is expired, the public link won't work anymore.

If the share is already published, this is a no-op (resulting in a successful response).

If the share was previously published the request can control, wether the old id should be reused (resulting in the same links as before), or a new random one should be generated.

If a share is currently published it can be un-published using this endpoint.

Returns a file from a share.

The response supports byte-serving and ETag.

Deletes a file from a share.

Allows to create a new share by uploading data using multipart/form-data requests. All requests must have content type multipart/form-data.

All parts of a multipart/form-data request are treated as files except if one with name "meta" is found. This is expected to contain a JSON structure with the metadata (validity, password etc). If this is missing, default values will be used. All other parts are added as files to the new share. It is allowed to send only a "meta" part or even an empty body. In these cases the new share will be created without files..

If this route is at /alias/ a Sharry-Alias header is required.

Allows to create a new share by uploading data using multipart/form-data requests. All requests must have content type multipart/form-data.

All parts of a multipart/form-data request are treated as files except if one with name "meta" is found. This is expected to contain a JSON structure with the metadata (validity, password etc). If this is missing, default values will be used. All other parts are added as files to the new share. It is allowed to send only a "meta" part or even an empty body. In these cases the new share will be created without files..

If this route is at /alias/ a Sharry-Alias header is required.

This endpoint allows to only upload json data to create a new empty share.

The same thing can be achieved by using multipart/form-data requests to the /sec/upload endpoint containing only one part named "meta". But this endpoint may be more convenient to use.

If this route is at /alias/ a Sharry-Alias header is required.

This endpoint allows to only upload json data to create a new empty share.

The same thing can be achieved by using multipart/form-data requests to the /sec/upload endpoint containing only one part named "meta". But this endpoint may be more convenient to use.

If this route is at /alias/ a Sharry-Alias header is required.

This endpoint can be used to add more files to an existing share. It must be a multipart/form-data request, where each part results in a new file added to the share.

If this route is at /alias/ a Sharry-Alias header is required.

This endpoint can be used to add more files to an existing share. It must be a multipart/form-data request, where each part results in a new file added to the share.

If this route is at /alias/ a Sharry-Alias header is required.

Implements the TUS protocol OPTIONS request to return common information about what parts of the tus protocol are supported by this server.

Please see the protocol specification for more details.

If this is the /alias route, a Sharry-Alias header is required.

Create a new (empty) file via tus' creation extension.

This follows the tus protocol, but uses different headers for transporting the filename and filetype. While the tus protocol defines a Upload-Metadata header, what it can contain is not specified. It requires custom negotiation between server and client, so we can as well use different headers that are easier to read and write:

• Sharry-File-Name specifies the filename (percent-encoded)
• Sharry-File-Type specifies the content type
• Sharry-File-Length can be used to specifiy the total length in bytes. If not found Upload-Length is used.

The total length must be specified, name and content type are optional.

Please see the protocol specification for more details.

Implements the TUS protocol OPTIONS request to return common information about what parts of the tus protocol are supported by this server.

Please see the protocol specification for more details.

If this is the /alias route, a Sharry-Alias header is required.

Create a new (empty) file via tus' creation extension.

This follows the tus protocol, but uses different headers for transporting the filename and filetype. While the tus protocol defines a Upload-Metadata header, what it can contain is not specified. It requires custom negotiation between server and client, so we can as well use different headers that are easier to read and write:

• Sharry-File-Name specifies the filename (percent-encoded)
• Sharry-File-Type specifies the content type
• Sharry-File-Length can be used to specifiy the total length in bytes. If not found Upload-Length is used.

The total length must be specified, name and content type are optional.

Please see the protocol specification for more details.

Endpoint for receiving the binary data belonging to a file. The file must have been created before using a POST request to the parent path url.

The Upload-Offset header must be specified, it may be set to 0.

You may also use the POST method instead.

Please see the protocol specification for more details.

Returns the upload status of the file. Returns the total expected length and the number of bytes that have really been saved. This is used by clients to determine the next Upload-Offset to use.

Please see the protocol specification for more details.

Endpoint for receiving the binary data belonging to a file. The file must have been created before using a POST request to the parent path url.

The Upload-Offset header must be specified, it may be set to 0.

You may also use the POST method instead.

Please see the protocol specification for more details.

Returns the upload status of the file. Returns the total expected length and the number of bytes that have really been saved. This is used by clients to determine the next Upload-Offset to use.

Please see the protocol specification for more details.

Returns all details about a share.

If the share is password protected, the password must be supplied using the header Sharry-Password. If it is not supplied, a 401 response is sent. If it is wrong, a 403 response will be returned.

Returns a file from a share.

The response supports byte-serving and ETag.

After uploading some files via an alias page, the client can request to notify the owner via e-mail that an upload just finished.

The corresponding user must have an e-mail address in their account and the mail feautre must be enabled in the config file.

To send a link to a published share via e-mail, templates can be specified in the configuration file. The server can then insert the required data (like the cryptic url), so the user is freed from copy-pasting things.

To send a link to an alias page via e-mail, templates can be specified in the configuration file. The server can then insert the required data (like the cryptic url), so the user is freed from copy-pasting things.

This will send the given e-mail as is to the specified recipients. This will only work, if the server enabled the mail feature.