can check if the current version has a known vulnerability, with the option to panic and exit if so, and otherwise show a warning in the controlpanel for admins
---------
Co-authored-by: ed <s@ocv.me>
previously, only .md files were editable with permissions read+write;
all other file-extensions required the delete-permission in addition
rw_edit is the list of file-extensions to allow read+write editing of
replace the heavyhanded connection:close added in b4fddbc3d
with a comparison of content-length to num bytes consumed
this approach also covers incorrectly configured servers
where the reverseproxy was not detected
also adds explicit TE/CL handling, even though most
(all?) reverseproxies already prevent such issues
also adds explicit sanchk of up2k chunk-receiver,
in case any bugs are ever added there
if both `quota-available-bytes` and `quotaused` are ignored
(not even returned as 404), then macos Finder is able to
connect instantly, avoiding this longstanding bug in macos
the presence of `quotaused` is the trigger for this logic, which
is a property apple invented and only apple uses, meaning we can
safely break the webdav spec as required in this case
thx @freddyheppell for the observation
`up-site` will override the scheme and domain (https://example.com/)
in the links to newly uploaded files, making it possible to upload a
file from a LAN IP while obtaining an external URL in return
`shr-site` will override the scheme and domain (https://example.com/)
in the link to a newly created share, making it possible to create a
share from a LAN IP while obtaining an external URL in return
---------
Co-authored-by: mechabubba <stevenvanniisprettycool@gmail.com>
there are webdav-clients (for example zotero) which fully pretend
to be a graphical webbrowser, going as far as faking the firefox
user-agent, which means they get the graphical login-page
instead of 401 (basic-authentication challenge)
these webdav-clients unfortunately also refuse to send credentials
unless they get 401'd, so until now it was impossible to connect them
the obvious solution of adding a suffix to
links in PROPFIND responses is a nonstarter;
* windows-webdav ignores the <displayname> property and shows the
<href> as the filename, so this would show up in windows explorer
and probably make most file operations impossible
* rclone is the opposite; ignores the <href> property (so it wouldn't
even see the suffix) and builds its own URL from the <displayname>
so we need a new weapon:
gloabl-option dav-port makes copyparty listen on another port which
is dedicated to webdav-clients that otherwise don't look the part
global-option p-nodav is the opposite; tags a listening-port as
only accepting connections from graphical browsers, just in case
closes#1142
