The Share button moved into .share-options in bdb5a6c sat flush
against the section bottom border. Adds 20px bottom padding plus
margin-top:16px and margin-left:auto on the button so it aligns
right with the Close button below.
After successful POST /api/s/{token}/verify, the server issues a
short-lived signed JWT cookie (oxi_share_unlock_<token>; HttpOnly;
SameSite=Lax; 1h TTL). Subsequent /api/s/{token} and
/api/s/{token}/download requests honour the cookie to bypass the
password gate, so password-protected file downloads work end-to-end.
- New module src/infrastructure/services/share_unlock_cookie.rs:
issue_jwt, verify_jwt, extract_from_cookie_header, build_set_cookie
+ 10 unit tests.
- New ShareService methods issue_unlock_jwt and
get_shared_link_with_unlock; trait method get_shared_link_by_token
delegates to a private fetch_share_resolved with an
allow_password_protected flag.
- access_shared_item, verify_shared_item_password, and
download_shared_file honour the unlock cookie.
Reuses OXICLOUD_JWT_SECRET, no new env var. Auth-token JWTs and
unlock-cookie JWTs cannot be confused: auth requires
username/email/role/jti claims, unlock has only sub/exp/iat.
Cross-share replay rejected via claims.sub == requested_token check.
a drop outside of the browser will:
- upload the file if only 1 file selected
- upload a .zip of the directory or multiple selection (browsers do not permit multiple upload yet)
note: I had to create a new handler because a post request to /api/batch/download is possible via JS but it will create a memory blob in the browser, during the drag action.
This may exhaust the browser's memory if heavy files
This will initiate zip creation from the server even if drop is canceled
The best approach is to add a handler supporting GET calls, this call will be triggered by the browser on drop action outside of it's window
a drop outside of the browser will:
- upload the file if only 1 file selected
- upload a .zip of the directory or multiple selection (browsers do not permit multiple upload yet)
note: I had to create a new handler because a post request to /api/batch/download is possible via JS but it will create a memory blob in the browser, during the drag action.
This may exhaust the browser's memory if heavy files
This will initiate zip creation from the server even if drop is canceled
The best approach is to add a handler supporting GET calls, this call will be triggered by the browser on drop action outside of it's window
# rustls-webpki 0.101.7 — three advisories, all transitive via AWS SDK → rustls 0.21.12.
# aws-sdk-s3 1.x (latest) has not yet migrated to rustls 0.23.x; no upgrade path available.
# Severity: low — exploitation requires either a rogue CA or a MitM on AWS S3 infrastructure.
# RUSTSEC-2026-0104: DoS via panic in CRL parsing (only if CRLs are processed).
# RUSTSEC-2026-0098: URI name constraints ignored (requires CA misissuance).
# RUSTSEC-2026-0099: Wildcard name constraint bypass (requires CA misissuance).
"RUSTSEC-2026-0104",
"RUSTSEC-2026-0098",
"RUSTSEC-2026-0099",
# instant unmaintained — transitive via azure_core 0.21.0 (latest available).
# No direct security impact; no upgrade path exists.
"RUSTSEC-2024-0384",
The PROPFIND handlers (added in #153) handle the /caldav/{username}/ and
/carddav/{username}/ prefixes returned by discovery, but do so via an
expensive database call to distinguish usernames from UUIDs. The remaining
handlers (PUT, GET, DELETE, REPORT, PROPPATCH) don't handle the prefix
at all, causing 500 errors when standard clients (DAVx5, Apple Calendar,
Thunderbird) follow the discovery URLs.
This commit:
1. Adds a strip_username_prefix() helper that uses a UUID parse check
to distinguish collection IDs from usernames (no DB call needed).
2. Applies it to PUT, GET, DELETE, REPORT, and PROPPATCH handlers in
both caldav_handler.rs and carddav_handler.rs.
3. Refactors PROPFIND in both files to use the same UUID heuristic for
consistency, avoiding unnecessary database queries.
Includes 7 unit tests for the helper function.
Dionisio Pozo