From c65dd86d5ee8485a9ea2a674e8caae8d6609a9e9 Mon Sep 17 00:00:00 2001 From: Ilias Trichopoulos Date: Mon, 5 Oct 2020 11:29:18 +0200 Subject: [PATCH] Fix typos (#181) --- dataprovider/dataprovider.go | 2 +- docs/account.md | 2 +- docs/check-password-hook.md | 4 ++-- docs/dynamic-user-mod.md | 10 +++++----- docs/external-auth.md | 6 +++--- docs/full-configuration.md | 12 ++++++------ docs/google-cloud-storage.md | 2 +- docs/keyboard-interactive.md | 6 +++--- docs/post-connect-hook.md | 6 +++--- docs/s3.md | 2 +- docs/ssh-commands.md | 4 ++-- docs/virtual-folders.md | 4 ++-- docs/webdav.md | 10 +++++----- 13 files changed, 35 insertions(+), 35 deletions(-) diff --git a/dataprovider/dataprovider.go b/dataprovider/dataprovider.go index 3c219cd8..b8fb26be 100644 --- a/dataprovider/dataprovider.go +++ b/dataprovider/dataprovider.go @@ -202,7 +202,7 @@ type Config struct { // easily write his own authentication hooks. ExternalAuthHook string `json:"external_auth_hook" mapstructure:"external_auth_hook"` // ExternalAuthScope defines the scope for the external authentication hook. - // - 0 means all supported authetication scopes, the external hook will be executed for password, + // - 0 means all supported authentication scopes, the external hook will be executed for password, // public key and keyboard interactive authentication // - 1 means passwords only // - 2 means public keys only diff --git a/docs/account.md b/docs/account.md index cba1a462..8305f879 100644 --- a/docs/account.md +++ b/docs/account.md @@ -65,6 +65,6 @@ These properties are stored inside the data provider. If you want to use your existing accounts, you have these options: -- If your accounts are aleady stored inside a supported database, you can create a database view. Since a view is read only, you have to disable user management and quota tracking so SFTPGo will never try to write to the view +- If your accounts are already stored inside a supported database, you can create a database view. Since a view is read only, you have to disable user management and quota tracking so SFTPGo will never try to write to the view - you can import your users inside SFTPGo. Take a look at [sftpgo_api_cli.py](../examples/rest-api-cli#convert-users-from-other-stores "SFTPGo API CLI example"), it can convert and import users from Linux system users and Pure-FTPd/ProFTPD virtual users - you can use an external authentication program diff --git a/docs/check-password-hook.md b/docs/check-password-hook.md index e7605daa..7952c6b3 100644 --- a/docs/check-password-hook.md +++ b/docs/check-password-hook.md @@ -11,7 +11,7 @@ The expected response is a JSON serialized struct containing the following keys: - `status` integer. 0 means KO, 1 means OK, 2 means partial success - `to_verify` string. For `status` = 2 SFTPGo will check this password against the one stored inside SFTPGo data provider -If the hook defines an external program it can reads the following environment variables: +If the hook defines an external program it can read the following environment variables: - `SFTPGO_AUTHD_USERNAME` - `SFTPGO_AUTHD_PASSWORD` @@ -29,7 +29,7 @@ If the hook is an HTTP URL then it will be invoked as HTTP POST. The request bod - `ip` - `protocol`, possible values are `SSH`, `FTP`, `DAV` -If authentication succeed the HTTP response code must be 200 and the response body must contain the expected JSON serialized response described above. +If authentication succeeds the HTTP response code must be 200 and the response body must contain the expected JSON serialized response described above. The program hook must finish within 30 seconds, the HTTP hook timeout will use the global configuration for HTTP clients. diff --git a/docs/dynamic-user-mod.md b/docs/dynamic-user-mod.md index 22f4e602..0ebd4c31 100644 --- a/docs/dynamic-user-mod.md +++ b/docs/dynamic-user-mod.md @@ -5,15 +5,15 @@ To enable dynamic user modification, you must set the absolute path of your prog The external program can read the following environment variables to get info about the user trying to login: -- `SFTPGO_LOGIND_USER`, it contains the user trying to login serialized as JSON. A JSON serialized user id equal to zero means the user does not exists inside SFTPGo +- `SFTPGO_LOGIND_USER`, it contains the user trying to login serialized as JSON. A JSON serialized user id equal to zero means the user does not exist inside SFTPGo - `SFTPGO_LOGIND_METHOD`, possible values are: `password`, `publickey` and `keyboard-interactive` - `SFTPGO_LOGIND_IP`, ip address of the user trying to login - `SFTPGO_LOGIND_PROTOCOL`, possible values are `SSH`, `FTP`, `DAV` -The program must write, on its the standard output: +The program must write, on its standard output: - an empty string (or no response at all) if the user should not be created/updated -- or the SFTPGo user, JSON serialized, if you want create or update the given user +- or the SFTPGo user, JSON serialized, if you want to create or update the given user If the hook is an HTTP URL then it will be invoked as HTTP POST. The login method, the used protocol and the ip address of the user trying to login are added to the query string, for example `?login_method=password&ip=1.2.3.4&protocol=SSH`. The request body will contain the user trying to login serialized as JSON. If no modification is needed the HTTP response code must be 204, otherwise the response code must be 200 and the response body a valid SFTPGo user serialized as JSON. @@ -32,8 +32,8 @@ The program hook must finish within 30 seconds, the HTTP hook will use the globa If an error happens while executing the hook then login will be denied. -"Dynamic user creation or modification" and "External Authentication" are mutally exclusive, they are quite similar, the difference is that "External Authentication" returns an already authenticated user while using "Dynamic users modification" you simply create or update a user. The authentication will be checked inside SFTPGo. -In other words while using "External Authentication" the external program receives the credentials of the user trying to login (for example the clear text password) and it need to validate them. While using "Dynamic users modification" the pre-login program receives the user stored inside the dataprovider (it includes the hashed password if any) and it can modify it, after the modification SFTPGo will check the credentials of the user trying to login. +"Dynamic user creation or modification" and "External Authentication" are mutually exclusive, they are quite similar, the difference is that "External Authentication" returns an already authenticated user while using "Dynamic users modification" you simply create or update a user. The authentication will be checked inside SFTPGo. +In other words while using "External Authentication" the external program receives the credentials of the user trying to login (for example the cleartext password) and it needs to validate them. While using "Dynamic users modification" the pre-login program receives the user stored inside the dataprovider (it includes the hashed password if any) and it can modify it, after the modification SFTPGo will check the credentials of the user trying to login. Let's see a very basic example. Our sample program will grant access to the existing user `test_user` only in the time range 10:00-18:00. Other users will not be modified since the program will terminate with no output. diff --git a/docs/external-auth.md b/docs/external-auth.md index df0563b3..22682ca6 100644 --- a/docs/external-auth.md +++ b/docs/external-auth.md @@ -12,7 +12,7 @@ The external program can read the following environment variables to get info ab - `SFTPGO_AUTHD_KEYBOARD_INTERACTIVE`, not empty for keyboard interactive authentication Previous global environment variables aren't cleared when the script is called. The content of these variables is _not_ quoted. They may contain special characters. They are under the control of a possibly malicious remote user. -The program must write, on its standard output, a valid SFTPGo user serialized as JSON if the authentication succeed or a user with an empty username if the authentication fails. +The program must write, on its standard output, a valid SFTPGo user serialized as JSON if the authentication succeeds or a user with an empty username if the authentication fails. If the hook is an HTTP URL then it will be invoked as HTTP POST. The request body will contain a JSON serialized struct with the following fields: @@ -23,7 +23,7 @@ If the hook is an HTTP URL then it will be invoked as HTTP POST. The request bod - `public_key`, not empty for public key authentication - `keyboard_interactive`, not empty for keyboard interactive authentication -If authentication succeed the HTTP response code must be 200 and the response body a valid SFTPGo user serialized as JSON. If the authentication fails the HTTP response code must be != 200 or the response body must be empty. +If authentication succeeds the HTTP response code must be 200 and the response body a valid SFTPGo user serialized as JSON. If the authentication fails the HTTP response code must be != 200 or the response body must be empty. If the authentication succeeds, the user will be automatically added/updated inside the defined data provider. Actions defined for users added/updated will not be executed in this case and an already logged in user with the same username will not be disconnected, you have to handle these things yourself. @@ -32,7 +32,7 @@ The program hook must finish within 30 seconds, the HTTP hook timeout will use t This method is slower than built-in authentication, but it's very flexible as anyone can easily write his own authentication hooks. You can also restrict the authentication scope for the hook using the `external_auth_scope` configuration key: -- `0` means all supported authetication scopes. The external hook will be used for password, public key and keyboard interactive authentication +- `0` means all supported authentication scopes. The external hook will be used for password, public key and keyboard interactive authentication - `1` means passwords only - `2` means public keys only - `4` means keyboard interactive only diff --git a/docs/full-configuration.md b/docs/full-configuration.md index 67fc2fb9..4dfe1ade 100644 --- a/docs/full-configuration.md +++ b/docs/full-configuration.md @@ -62,7 +62,7 @@ The configuration file contains the following sections: - `bind_port`, integer. The port used for serving SFTP requests. Default: 2022 - `bind_address`, string. Leave blank to listen on all available network interfaces. Default: "" - `idle_timeout`, integer. Deprecated, please use the same key in `common` section. - - `max_auth_tries` integer. Maximum number of authentication attempts permitted per connection. If set to a negative number, the number of attempts is unlimited. If set to zero, the number of attempts are limited to 6. + - `max_auth_tries` integer. Maximum number of authentication attempts permitted per connection. If set to a negative number, the number of attempts is unlimited. If set to zero, the number of attempts is limited to 6. - `banner`, string. Identification string used by the server. Leave empty to use the default banner. Default `SFTPGo_`, for example `SSH-2.0-SFTPGo_0.9.5` - `upload_mode` integer. Deprecated, please use the same key in `common` section. - `actions`, struct. Deprecated, please use the same key in `common` section. @@ -84,13 +84,13 @@ The configuration file contains the following sections: - `bind_port`, integer. The port used for serving FTP requests. 0 means disabled. Default: 0. - `bind_address`, string. Leave blank to listen on all available network interfaces. Default: "". - `banner`, string. Greeting banner displayed when a connection first comes in. Leave empty to use the default banner. Default `SFTPGo ready`, for example `SFTPGo 1.0.0-dev ready`. - - `banner_file`, path to the banner file. The contents of the specified file, if any, are diplayed when someone connects to the server. It can be a path relative to the config dir or an absolute one. If set, it overrides the banner string provided by the `banner` option. Leave empty to disable. + - `banner_file`, path to the banner file. The contents of the specified file, if any, are displayed when someone connects to the server. It can be a path relative to the config dir or an absolute one. If set, it overrides the banner string provided by the `banner` option. Leave empty to disable. - `active_transfers_port_non_20`, boolean. Do not impose the port 20 for active data transfers. Enabling this option allows to run SFTPGo with less privilege. Default: false. - `force_passive_ip`, ip address. External IP address to expose for passive connections. Leavy empty to autodetect. Defaut: "". - `passive_port_range`, struct containing the key `start` and `end`. Port Range for data connections. Random if not specified. Default range is 50000-50100. - `certificate_file`, string. Certificate for FTPS. This can be an absolute path or a path relative to the config dir. - `certificate_key_file`, string. Private key matching the above certificate. This can be an absolute path or a path relative to the config dir. If both the certificate and the private key are provided the server will accept both plain FTP an explicit FTP over TLS. Certificate and key files can be reloaded on demand sending a `SIGHUP` signal on Unix based systems and a `paramchange` request to the running service on Windows. - - `tls_mode`, integer. 0 means accept both cleartext and encrypted sessions. 1 means TLS in required for both control and data connection. Do not enable this blindly, please check that a proper TLS config is in place or no login will be allowed if `tls_mode` is 1. + - `tls_mode`, integer. 0 means accept both cleartext and encrypted sessions. 1 means TLS is required for both control and data connection. Do not enable this blindly, please check that a proper TLS config is in place or no login will be allowed if `tls_mode` is 1. - **webdavd**, the configuration for the WebDAV server, more info [here](./webdav.md) - `bind_port`, integer. The port used for serving WebDAV requests. 0 means disabled. Default: 0. - `bind_address`, string. Leave blank to listen on all available network interfaces. Default: "". @@ -130,11 +130,11 @@ The configuration file contains the following sections: - `hook`, string. Absolute path to the command to execute or HTTP URL to notify. - `external_auth_program`, string. Deprecated, please use `external_auth_hook`. - `external_auth_hook`, string. Absolute path to an external program or an HTTP URL to invoke for users authentication. See [External Authentication](./external-auth.md) for more details. Leave empty to disable. - - `external_auth_scope`, integer. 0 means all supported authetication scopes (passwords, public keys and keyboard interactive). 1 means passwords only. 2 means public keys only. 4 means key keyboard interactive only. The flags can be combined, for example 6 means public keys and keyboard interactive + - `external_auth_scope`, integer. 0 means all supported authentication scopes (passwords, public keys and keyboard interactive). 1 means passwords only. 2 means public keys only. 4 means key keyboard interactive only. The flags can be combined, for example 6 means public keys and keyboard interactive - `credentials_path`, string. It defines the directory for storing user provided credential files such as Google Cloud Storage credentials. This can be an absolute path or a path relative to the config dir - `pre_login_program`, string. Deprecated, please use `pre_login_hook`. - `pre_login_hook`, string. Absolute path to an external program or an HTTP URL to invoke to modify user details just before the login. See [Dynamic user modification](./dynamic-user-mod.md) for more details. Leave empty to disable. - - `post_login_hook`, string. Absolute path to an external program or an HTTP URL to invoke to notify a successul or failed login. See [Post-login hook](./post-login-hook.md) for more details. Leave empty to disable. + - `post_login_hook`, string. Absolute path to an external program or an HTTP URL to invoke to notify a successful or failed login. See [Post-login hook](./post-login-hook.md) for more details. Leave empty to disable. - `post_login_scope`, defines the scope for the post-login hook. 0 means notify both failed and successful logins. 1 means notify failed logins. 2 means notify successful logins. - `check_password_hook`, string. Absolute path to an external program or an HTTP URL to invoke to check the user provided password. See [Check password hook](./check-password-hook.md) for more details. Leave empty to disable. - `check_password_scope`, defines the scope for the check password hook. 0 means all protocols, 1 means SSH, 2 means FTP, 4 means WebDAV. You can combine the scopes, for example 6 means FTP and WebDAV. @@ -159,7 +159,7 @@ The configuration file contains the following sections: A full example showing the default config (in JSON format) can be found [here](../sftpgo.json). -If you want to use a private host key that use an algorithm/setting different from the auto generated RSA/ECDSA keys, or more than two private keys, you can generate your own keys and replace the empty `keys` array with something like this: +If you want to use a private host key that uses an algorithm/setting different from the auto generated RSA/ECDSA keys, or more than two private keys, you can generate your own keys and replace the empty `keys` array with something like this: ```json "host_keys": [ diff --git a/docs/google-cloud-storage.md b/docs/google-cloud-storage.md index 92e59e0d..772f1d23 100644 --- a/docs/google-cloud-storage.md +++ b/docs/google-cloud-storage.md @@ -8,6 +8,6 @@ You can optionally specify a [storage class](https://cloud.google.com/storage/do The configured bucket must exist. -Google Cloud Storage is exposed over HTTPS so if you are running SFTPGo as docker image please be sure to uncomment the line that install `ca-certificates`, inside your `Dockerfile`, to be able to properly verify certificate authorities. +Google Cloud Storage is exposed over HTTPS so if you are running SFTPGo as docker image please be sure to uncomment the line that installs `ca-certificates`, inside your `Dockerfile`, to be able to properly verify certificate authorities. This backend is very similar to the [S3](./s3.md) backend, and it has the same limitations. diff --git a/docs/keyboard-interactive.md b/docs/keyboard-interactive.md index 89e0beda..0f13e2bd 100644 --- a/docs/keyboard-interactive.md +++ b/docs/keyboard-interactive.md @@ -81,11 +81,11 @@ The request body will contain a JSON struct with the following fields: - `ip`, string - `password`, string. This is the hashed password as stored inside the data provider - `answers`, list of string. It will be null for the first request -- `questions`, list of string. It will contains the previous asked questions. It will be null for the first request +- `questions`, list of string. It will contain the previously asked questions. It will be null for the first request The HTTP response code must be 200 and the body must contain the same JSON struct described for the program. -Let's see a basic sample, the configured hook is `http://127.0.0.1:8000/keyIntHookPwd`, as soon as the user try to login, SFTPGo makes this HTTP POST request: +Let's see a basic sample, the configured hook is `http://127.0.0.1:8000/keyIntHookPwd`, as soon as the user tries to login, SFTPGo makes this HTTP POST request: ```shell POST /keyIntHookPwd HTTP/1.1 @@ -126,7 +126,7 @@ Accept-Encoding: gzip {"request_id":"bq1r5r7cdrpd2qtn25ng","username":"a","ip":"127.0.0.1","password":"$pbkdf2-sha512$150000$ClOPkLNujMTL$XktKy0xuJsOfMYBz+f2bIyPTdbvDTSnJ1q+7+zp/HPq5Qojwp6kcpSIiVHiwvbi8P6HFXI/D3UJv9BLcnQFqPA==","answers":["OK"],"questions":["Password: "]} ``` -Here is the HTTP response that istructs SFTPGo to ask for a new question: +Here is the HTTP response that instructs SFTPGo to ask for a new question: ```shell HTTP/1.1 200 OK diff --git a/docs/post-connect-hook.md b/docs/post-connect-hook.md index 0669a4a6..0192bed1 100644 --- a/docs/post-connect-hook.md +++ b/docs/post-connect-hook.md @@ -1,12 +1,12 @@ # Post-connect hook -This hook is executed as soon as a new connection is estabilished. It notifies the connection's IP address and protocol. Based on the received response, the connection is accepted or rejected. Combining this hook with the [Post-login hook](./post-login-hook.md) you can implement your own (even for Protocol) blacklist/whitelist of IP addresses. +This hook is executed as soon as a new connection is established. It notifies the connection's IP address and protocol. Based on the received response, the connection is accepted or rejected. Combining this hook with the [Post-login hook](./post-login-hook.md) you can implement your own (even for Protocol) blacklist/whitelist of IP addresses. Please keep in mind that you can easily configure specialized program such as [Fail2ban](http://www.fail2ban.org/) for brute force protection. Executing a hook for each connection can be heavy. The `post-connect-hook` can be defined as the absolute path of your program or an HTTP URL. -If the hook defines an external program it can reads the following environment variables: +If the hook defines an external program it can read the following environment variables: - `SFTPGO_CONNECTION_IP` - `SFTPGO_CONNECTION_PROTOCOL` @@ -21,6 +21,6 @@ If the hook defines an HTTP URL then this URL will be invoked as HTTP GET with t - `ip` - `protocol` -The connection is accepted if the HTTP response code is `200` otherwise rejeted. +The connection is accepted if the HTTP response code is `200` otherwise rejected. The HTTP request will use the global configuration for HTTP clients. diff --git a/docs/s3.md b/docs/s3.md index 3e7f9060..e7932a1d 100644 --- a/docs/s3.md +++ b/docs/s3.md @@ -10,7 +10,7 @@ AWS SDK has different options for credentials. [More Detail](https://docs.aws.am So, you need to provide access keys to activate option 1, or leave them blank to use the other ways to specify credentials. -Most S3 backends require HTTPS connections so if you are running SFTPGo as docker image please be sure to uncomment the line that install `ca-certificates`, inside your `Dockerfile`, to be able to properly verify certificate authorities. +Most S3 backends require HTTPS connections so if you are running SFTPGo as docker image please be sure to uncomment the line that installs `ca-certificates`, inside your `Dockerfile`, to be able to properly verify certificate authorities. Specifying a different `key_prefix`, you can assign different "folders" of the same bucket to different users. This is similar to a chroot directory for local filesystem. Each SFTP/SCP user can only access the assigned folder and its contents. The folder identified by `key_prefix` does not need to be pre-created. diff --git a/docs/ssh-commands.md b/docs/ssh-commands.md index b4ae6769..288e6a0a 100644 --- a/docs/ssh-commands.md +++ b/docs/ssh-commands.md @@ -10,7 +10,7 @@ For system commands we have no direct control on file creation/deletion and so t - quota check is suboptimal - maximum size restriction on single file is not respected - If quota is enabled and SFTPGo receives a system command, the used size and number of files are checked at the command start and not while new files are created/deleted. While the command is running the number of files is not checked, the remaining size is calculated as the difference between the max allowed quota and the used one, and it is checked against the bytes transferred via SSH. The command is aborted if it uploads more bytes than the remaining allowed size calculated at the command start. Anyway, we only see the bytes that the remote command sends to the local one via SSH. These bytes contain both protocol commands and files, and so the size of the files is different from the size trasferred via SSH: for example, a command can send compressed files, or a protocol command (few bytes) could delete a big file. To mitigate these issues, quotas are recalculated at the command end with a full scan of the directory specified for the system command. This could be heavy for big directories. If you need system commands and quotas you could consider disabling quota restrictions and periodically update quota usage yourself using the REST API. + If quota is enabled and SFTPGo receives a system command, the used size and number of files are checked at the command start and not while new files are created/deleted. While the command is running the number of files is not checked, the remaining size is calculated as the difference between the max allowed quota and the used one, and it is checked against the bytes transferred via SSH. The command is aborted if it uploads more bytes than the remaining allowed size calculated at the command start. Anyway, we only see the bytes that the remote command sends to the local one via SSH. These bytes contain both protocol commands and files, and so the size of the files is different from the size transferred via SSH: for example, a command can send compressed files, or a protocol command (few bytes) could delete a big file. To mitigate these issues, quotas are recalculated at the command end with a full scan of the directory specified for the system command. This could be heavy for big directories. If you need system commands and quotas you could consider disabling quota restrictions and periodically update quota usage yourself using the REST API. For these reasons we should limit system commands usage as much as possible, we currently support the following system commands: @@ -29,7 +29,7 @@ At least the following permissions are required to be able to run system command For `rsync` we cannot avoid that it creates symlinks so if the `create_symlinks` permission is granted we add the option `--safe-links`, if it is not already set, to the received `rsync` command. This should prevent to create symlinks that point outside the home directory. If the user cannot create symlinks we add the option `--munge-links`, if it is not already set, to the received `rsync` command. This should make symlinks unusable (but manually recoverable). -SFTPGo support the following built-in SSH commands: +SFTPGo supports the following built-in SSH commands: - `scp`, SFTPGo implements the SCP protocol so we can support it for cloud filesystems too and we can avoid the other system commands limitations. SCP between two remote hosts is supported using the `-3` scp option. - `md5sum`, `sha1sum`, `sha256sum`, `sha384sum`, `sha512sum`. Useful to check message digests for uploaded files. diff --git a/docs/virtual-folders.md b/docs/virtual-folders.md index e93449e4..6ccb225f 100644 --- a/docs/virtual-folders.md +++ b/docs/virtual-folders.md @@ -1,6 +1,6 @@ # Virtual Folders -A virtual folder is a mapping between a SFTP/SCP virtual path and a filesystem path outside the user home directory. +A virtual folder is a mapping between an SFTP/SCP virtual path and a filesystem path outside the user home directory. The specified paths must be absolute and the virtual path cannot be "/", it must be a sub directory. The parent directory to the specified virtual path must exist. SFTPGo will try to automatically create any missing parent directory for the configured virtual folders at user login. @@ -16,7 +16,7 @@ For example if you configure `/tmp/mapped` or `C:\mapped` as mapped path and `/v The same virtual folder, identified by the `mapped_path`, can be shared among users and different folder quota limits for each user are supported. Folder quota limits can also be included inside the user quota but in this case the folder is considered "private" and sharing it with other users will break user quota calculation. -You don't need to create virtual folders, inside the data provider, to associate them to the users: any missing virtual folder will be automatically created when you add/update an user. You only have to create the folder on the filesystem. +You don't need to create virtual folders, inside the data provider, to associate them to the users: any missing virtual folder will be automatically created when you add/update a user. You only have to create the folder on the filesystem. Using the REST API you can: diff --git a/docs/webdav.md b/docs/webdav.md index 03ab305f..b233d181 100644 --- a/docs/webdav.md +++ b/docs/webdav.md @@ -1,6 +1,6 @@ # WebDAV -The experimental `WebDAV` support can be enabled setting a `bind_port` inside the `webdavd` configuration section. +The experimental `WebDAV` support can be enabled by setting a `bind_port` inside the `webdavd` configuration section. Each user has his own path like `http/s://:/` and it must authenticate using password credentials. @@ -9,7 +9,7 @@ If you enable quota support a dataprovider query is required, to update the user The caching configuration allows to set: -- `expiration_time` in minutes. If a user is cached for more than the specificied minutes it will be removed from the cache and a new dataprovider query will be performed. Please note that the `last_login` field will not be updated and `external_auth_hook`, `pre_login_hook` and `check_password_hook` will not be executed if the user is obtained from the cache. +- `expiration_time` in minutes. If a user is cached for more than the specified minutes it will be removed from the cache and a new dataprovider query will be performed. Please note that the `last_login` field will not be updated and `external_auth_hook`, `pre_login_hook` and `check_password_hook` will not be executed if the user is obtained from the cache. - `max_size`. Maximum number of users to cache. When this limit is reached the user with the oldest expiration date will be removed from the cache. 0 means no limit however the cache size cannot exceed the number of users so if you have a small number of users you can leave this setting to 0. Users are automatically removed from the cache after an update/delete. @@ -18,11 +18,11 @@ WebDAV should work as expected for most use cases but there are some minor issue Know issues: -- removing a directory tree on Cloud Storage backends could generate a `not found` error when removing the last (virtual) directory. This happen if the client cycles the directories tree itself and removes files and directories one by one instead of issuing a single remove command -- the used [WebDAV library](https://pkg.go.dev/golang.org/x/net/webdav?tab=doc) asks to open a file to execute a `stat` and sometime reads some bytes to find the content type. We are unable to distinguish a `stat` from a `download` for now, so to be able to proper list a directory you need to grant both `list` and `download` permissions +- removing a directory tree on Cloud Storage backends could generate a `not found` error when removing the last (virtual) directory. This happens if the client cycles the directories tree itself and removes files and directories one by one instead of issuing a single remove command +- the used [WebDAV library](https://pkg.go.dev/golang.org/x/net/webdav?tab=doc) asks to open a file to execute a `stat` and sometimes reads some bytes to find the content type. We are unable to distinguish a `stat` from a `download` for now, so to be able to properly list a directory you need to grant both `list` and `download` permissions - the used `WebDAV library` not always returns a proper error code/message, most of the times it simply returns `Method not Allowed`. I'll try to improve the library error codes in the future - if an object within a directory cannot be accessed, for example due to OS permissions issues or because is a missing mapped path for a virtual folder, the directory listing will fail. In SFTP/FTP the directory listing will succeed and you'll only get an error if you try to access to the problematic file/directory We plan to add [Dead Properties](https://tools.ietf.org/html/rfc4918#section-3) support in future releases. We need a design decision here, probably the best solution is to store dead properties inside the data provider but this could increase a lot its size. Alternately we could store them on disk for local filesystem and add as metadata for Cloud Storage, this means that we need to do a separate `HEAD` request to retrieve dead properties for an S3 file. For big folders will do a lot of requests to the Cloud Provider, I don't like this solution. Another option is to expose a hook and allow you to implement `dead properties` outside SFTPGo. -If you find any other quircks or problems please let us know opening a GitHub issue, thank you! +If you find any other quirks or problems please let us know opening a GitHub issue, thank you!