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
`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
seemingly as of iOS / macos 26.1, safari started requesting
favicons -- specifically only favicons -- with the incorrect
browser context (they probably forgot to initialize something)
instead of the correct user-agent, it would send:
* iOS: NetworkingExtension/8623.1.14.10.9
* macos: com.apple.WebKit.Networking/21623.1.14.11.9
further, it would NOT send any SameSite=Strict cookies,
which the session-cookie is (for good reason)
putting these two together, safari now looks like a webdav client,
and copyparty sends the only appropriate response (http 401),
resulting in a basic-authentication popup
left with no good options, this is what we can do to mitigate:
* add a new option --ua-nodav which is a regex of user-agents
which are definitely not webdav clients, as macos-finder still
flipflops between WebDAVLib/1.3 and WebDAVFS/3.0.0 like normal
* use the "js=y" cookie as another flag that this is a webbrowser
merry christmas
some reverseproxies do not include a compatible alternative to
x-forwarded-proto by default, while also lacking the option to
set custom headers
add --xf-proto-fb to set a fixed protocol to assume
also closes#1053, a PR which inspired this commit heavily
(slightly different approach for flexibility and performance)
Co-authored-by: Dawson Jeane <dawsonmjeane@gmail.com>
uploading a folder named COMPLE:X into exfat on linux would fail
because exfat behaves like windows, rejecting <>:|?*"\/
this would also fail on windows, but then due to
sanitize_fn being overly aggressive
fix this by detecting filesystem traits on startup and
also translating vpath early on windows
plus these fixes:
* adds a previously missed libvips optimization,
giving much smaller files at the same quality
* try to align the quality-scale of each backend
(pillow, libvips, ffmpeg) by filesize
if x-forwarded-for is present, then also require
x-forwarded-host and x-forwarded-proto
avoids displaying subtly-incorrect values on the connect-page
and instead shows blatantly-incorrect values ("example.com")
the headernames x-forwarded-host and x-forwarded-proto can
be configured with global-options xf-host and xf-proto
* button "dl" in settings UI (always takes precedence)
* global-option and/or volflag "dlni"
* url-parameter ?dlni or ?dlni=0
the preference is applied per-volume when navigating between folders,
unless the settings-button has been toggled, which overrides that
hooks returning exitcode 0 will:
* run the next hook, if any
* allow the original action, unless successive hook opposes
hooks returning exitcode 100 will:
* abort running successive hooks
* allow the original action
hooks returning anything other than 0 or 100 will:
* abort running successive hooks
* REJECT the original action
zmq can now respond with json; a dict with "rc", "rejectmsg",
"reloc" and so on, just like other hooks replying with json
