previously: threading.Condition to wakeup the actual handler;
exciting chance of heisenbugs / deadlocks (theoretically)
almost went with os.pipe on unix and socketpairs on windows,
but turns out SimpleQueue is perfect and safe for this purpose
SimpleQueue is 3.7+ so use a regular queue on <3.7
(same problems as original approach)
also need dedicated thread for popping the queue on <3.7
to avoid deadlock on most platforms (--sig-thr)
new features:
--logrot-sig sets a signal for immediate log-rotate
--stack-sig sets a signal to dump stack to log/stdout
--reload-sig sets a signal to initiates config-reload
(was hardcoded to USR1 previously)
rawpy is still supported but will not be bundled by default
due to security concerns
dcraw_emu reads more formats than rawpy + gives better quality
(we told rawpy to use embedded thumbs), so also much slower
dcraw_emu must be combined with libvips or pillow (equivalent)
other alternatives considered:
libvips + a full imagemagick does a different subset of formats,
less than dcraw_emu, yet is 3x slower and eats ram
magick wins wrt formats but is even slower (4x of dcraw_emu)
only expand environment-variables of the form ${ENV}
by default, crash on startup if the old $ENV syntax is found,
explaning that the old syntax can be enabled with an option
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
`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
