proxy

var Help = strings.ReplaceAll(`### Auth Proxy

If you supply the parameter |--auth-proxy /path/to/program| then
rclone will use that program to generate backends on the fly which
then are used to authenticate incoming requests.  This uses a simple
JSON based protocol with input on STDIN and output on STDOUT.

**PLEASE NOTE:** |--auth-proxy| and |--authorized-keys| cannot be used
together, if |--auth-proxy| is set the authorized keys option will be
ignored.

There is an example program
[bin/test_proxy.py](https://github.com/rclone/rclone/blob/master/bin/test_proxy.py)
in the rclone source code.

The program's job is to take a |user| and |pass| on the input and turn
those into the config for a backend on STDOUT in JSON format.  This
config will have any default parameters for the backend added, but it
won't use configuration from environment variables or command line
options - it is the job of the proxy program to make a complete
config.

This config generated must have this extra parameter

- |_root| - root to use for the backend

And it may have these parameters

- |_obscure| - comma separated strings for parameters to obscure
- |_secret_access_key| - the secret for S3 access key auth (see below)

If password authentication was used by the client, input to the proxy
process (on STDIN) would look similar to this:

|||json
{
  "user": "me",
  "pass": "mypassword",
  "client_ip": "192.168.1.1"
}
|||

If public-key authentication was used by the client, input to the
proxy process (on STDIN) would look similar to this:

|||json
{
  "user": "me",
  "public_key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQDuwESFdAe14hVS6omeyX7edc...JQdf",
  "client_ip": "192.168.1.1"
}
|||

If the client authenticated with an S3 access key (|rclone serve s3|),
the client never sends its secret, only a signature made with it, so
the input contains just the access key ID as the |user| with no |pass|
or |public_key|:

|||json
{
  "user": "AKIAIOSFODNN7EXAMPLE",
  "client_ip": "192.168.1.1"
}
|||

In this case the program must look up the secret access key for that
access key ID and return it in the |_secret_access_key| field of the
output. Rclone then uses that secret to verify the signature on the
request, refusing the request if it does not match. This means the
proxy program is the source of truth for both the credentials and the
backend they map to. If the program does not return
|_secret_access_key| or returns it empty the request is refused.

The program's answer for an access key ID is cached (see below) but
is checked with the program again after 5 minutes even if the access
key ID is in constant use, so revoking an access key ID in the
program takes effect within 5 minutes. A rotated secret takes effect
on the first request signed with it.

The |client_ip| key holds the IP address the client connected from,
without a port number.  It can be used to restrict logins to certain
networks, or to log authentication attempts centrally.  It is omitted if
the client has no IP address, for example when connecting over a unix
socket.  Note that if rclone is behind a reverse proxy this will be the
address of the reverse proxy and not the original client.

And as an example return this on STDOUT

|||json
{
  "type": "sftp",
  "_root": "",
  "_obscure": "pass",
  "user": "me",
  "pass": "mypassword",
  "host": "sftp.example.com"
}
|||

This would mean that an SFTP backend would be created on the fly for
the |user| and |pass|/|public_key| returned in the output to the host given.  Note
that since |_obscure| is set to |pass|, rclone will obscure the |pass|
parameter before creating the backend (which is required for sftp
backends).

The program can manipulate the supplied |user| in any way, for example
to make proxy to many different sftp backends, you could make the
|user| be |user@example.com| and then set the |host| to |example.com|
in the output and the user to |user|. For security you'd probably want
to restrict the |host| to a limited list.

An internal cache of backends is keyed on the |user|, a hash of the
|pass| or |public_key|, and the |client_ip|.  This means that if a
user's password or public-key changes, the client connects from a new IP
address, or the proxy returns different config parameters (eg a rotated
|api_key|), a fresh backend will be created on the next request rather
than the cached one being reused.

This can be used to build general purpose proxies to any kind of
backend that rclone supports.

`, "|", "`")

var OptionsInfo = fs.Options{{
	Name:    "auth_proxy",
	Default: "",
	Help:    "A program to use to create the backend from the auth",
}}