4530298398a78f1626a5474b55bbf1fe446ac8a1
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 surtic86andClaude Opus 5
|
4530298398 |
Cut over-engineering found by a repo-wide audit
- Config: auth, services, logging, queue and database only repeated the
framework's own files and are gone; the others keep only the keys that
differ (app version, cache serializable_classes, session cookie name,
Markdown mail theme, the shares disk, three Octane values, Livewire's
pagination theme and payload guards).
- Email verification is removed: User never implemented MustVerifyEmail,
so it was never enforced, and SealShare has a single admin and no
registration. CreateNewUser goes with it.
- FileEncryptionService::encryptFile() and generateSalt() were only used
by tests; tests build files with encryptTestFile() in tests/Pest.php.
- The expiration options are defined once, as Share::EXPIRATIONS. "30 Days"
now lasts 30 days instead of a calendar month, and Admin settings only
save a default expiration that is one of the options.
- One-caller helpers are inlined, the uploader reads chunk responses with
XHR's responseType, and starter-kit leftovers are removed.
- Docker: PHP reads the PHP_* limits from the environment itself
(${VAR:-default} in uploads.ini); both entrypoints stop writing the ini.
docker-compose.yml shares the app and scheduler variables through one
anchor. The dev image installs gd for the screenshot publisher and fake
test images.
- Development runs in Docker only: the composer dev script, concurrently,
laravel/pail, laravel/sail, autoprefixer and the shell-quote override
are gone.
- phpunit.xml forces the test environment with <server> entries, so tests
run in the dev container no longer use its real database.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
e057cada3d |
Count a share's download limit per recipient, not per file
With a download limit of 1, downloading one file of a share with several files deleted the share and the files not yet downloaded. ShareService::recordDownload() ran at the end of every download request, one file or the ZIP alike, and deleted the share as soon as download_count reached max_downloads. It has worked that way since the first commit. - One recipient's visit is one download. The first file or ZIP a session downloads is counted when it starts, in one conditional UPDATE that also checks the limit, so two recipients starting at once can't both take the last download. The session remembers the time, and for ShareService::DOWNLOAD_WINDOW_MINUTES (60) it may start more downloads of the share without counting them, even once the limit is reached. The claim happens in the controller before streaming, because the session is saved before the body is sent, and after the share key is resolved, so a request without the key uses nothing. - A share at its limit is closed to everyone else at once. The hourly cleanup deletes it 24 hours after shares.last_downloaded_at (new column), since a ZIP opens each file only when it reaches it and a large download can outlast the hour. - The download page of a limited share says how many downloads are left, switches to "You have 1 hour" on the first press (Alpine, as a download link does not render the page again), and shows the time left on the next visit. - The admin dashboard shows "2 of 3 downloads", marks shares at their limit "Download limit reached" and leaves them out of Active Shares. - Tests: the regression (3 files, limit 1: every file and the ZIP download, counted once), another recipient, the end of the hour, the last download going to one of two recipients, requests refused before streaming, unlimited shares, the page notes in PHP and in Chromium, the dashboard, and the cleanup at 23 and 25 hours. The tests of recordDownload() and of the instant deletion are gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
5853f1f7d6 |
Give every page the share pages' layout, at one width
The pages were built five ways: two layouts, seven widths from 28 to 64rem and four heading styles. Every page now looks like the share pages: a centred heading over one 40rem column of outlined cards, with the floating toolbar below. - <x-page> (components/page.blade.php) is the root of every page. It draws the h1 and its line (`brand` takes the site's logo, title and description from Admin settings), an optional `mark` and `navigation` slot, then the content. It has no width prop: every page is the same <x-pane width="narrow">. - The sign-in, password reset, confirm, verify email, two-factor challenge, setup and system password pages move onto layouts/app with the brand heading and their form in a card titled with the task. layouts/auth, auth-header and the settings heading partial are gone, and so is the per-page width CSS. - Settings put their section nav under the heading; the admin pages get a description line each. FileUploader and ShareDownload no longer pass the branding to their views. - The admin dashboard's table needed about 49rem, so its shares are a list: created above the token, which opens the share, then files, size, downloads and expiry on two lines that wrap instead of clipping, and one delete button. A "Sort by" select replaces the column headers (newest, oldest, expiring soonest with never-expiring last, largest, most downloads, most files) and resets the page. The stats stay two by two. table.css and sort-header.css are no longer imported. - Branding hints in Admin settings name every page the title shows on. - Tests: PageTemplateTest renders every page once and checks one page template, one h1 and the width, and the brand heading with its fallbacks. FrameTest measures the page column instead of the auth card and the 64rem main; dashboard tests follow the list and the sort select, including expiry order. .ai/rules/views.md records <x-page>, the CHANGELOG notes the change and the website screenshots are regenerated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
40e35bab0e |
Encrypt uploads in the browser and send them in chunks
A 6 GB upload kept a customer waiting long after its progress bar
reached 100%. The server wrote every upload three times: PHP's
temporary file, Livewire's copy of it ("Processing files...") and the
encrypted file ("Create Share Link"), each a full rewrite of a slow
disk. The unencrypted copy also stayed behind in livewire-tmp.
Now the uploader's browser encrypts each file in 16 MB chunks with
WebCrypto and PUTs them one at a time; the server checks each chunk in
memory and writes it once, already encrypted. Creating the share only
wraps its key and saves the options. A 200 MB upload through the
Docker image took 2.8 s, and its download matched byte for byte.
- SEALCHK2: a 19-byte header (chunk size, 7-byte nonce prefix), then
ciphertext and tag per chunk. Each nonce holds the chunk index and a
last-chunk flag (the STREAM construction), so cut or reordered files
fail to decrypt. SEALCHK1 and the single-block format still read.
- Envelope encryption: one random key per share. With a password it is
wrapped with Argon2id (sodium, libsodium's interactive limits) in
shares.wrapped_key, which names its parameters. Password shares from
before keep their PBKDF2-derived key.
- The upload page registers each selection with FileUploader into a
pending share of its own, lists the files with their progress, retries
a failed chunk after 1-16 s, then offers Retry; Remove and Cancel
abort. UploadChunkController only accepts chunks from the session that
started the share: a repeat is acknowledged, a skip gets 409 with the
count stored. Chunks go out as Blobs, which Chromium sends about eight
times faster than ArrayBuffers.
- Uploads need a secure context: over plain HTTP the page says HTTPS is
needed and takes no files. The Docker image gains AUTO_HTTPS, which
serves Let's Encrypt on 443 for SERVER_NAME and redirects 80; without
it the container stays on HTTP 80 behind a proxy. docker/Caddyfile was
never loaded and is gone; docker/healthcheck.sh covers both modes.
- "Download all" streams the ZIP with maennchen/zipstream-php (STORE,
ZIP64) instead of decrypting whole files into memory and writing the
archive unencrypted to /tmp.
- Pending shares count towards the quota, stay out of the admin
dashboard and 404 everywhere else. shares:cleanup deletes uploads idle
for 4 hours and Livewire temporary files older than that.
- PHP's upload limits no longer cap the admin's max file size and
default to 64M; LIVEWIRE_MAX_UPLOAD_TIME is gone and
UPLOAD_CHUNK_SIZE_MB is new.
- Tests cover the format, key wrapping, registration limits, the chunk
endpoint's answers, completing a share, the streamed ZIP, cleanup,
and in Chromium a real chunked upload and the HTTPS warning; the
selected-files overflow test runs again. README, website, CHANGELOG
and .ai/rules follow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
504971ad7f |
Generate share passwords and offer them again beside the new link
Uploaders no longer have to make up a share password. With "Password protect" on, the upload page has Generate and Copy under the field, and the page the upload leads to offers the password once more beside the link: masked, with the same copy button at the end of the field as the link's. The password also derives the share's encryption key and only its hash is stored, so a lost one means files nobody can open. - PasswordGeneratorService draws from Random\Randomizer's secure engine. Characters are drawn uniformly and redrawn until every chosen set appears; passphrases come from EFF's large word list (CC BY 3.0 US, credited in the README), without its four hyphenated words. - Admin settings gain a "Share Passwords" card: mode (off, on request, prefilled as protection is switched on), kind (characters: length 12–64, the sets, look-alikes left out; passphrase: 4–10 words and a separator), and an example with its estimated entropy that follows the form before saving. Fields the chosen mode or kind hides are excluded from validation and keep their saved value. The default is on request, 20 letters and numbers without look-alikes. - FileUploader flashes the password encrypted with the share's token; ShareCreated shows it only when the token matches, so a reload or any other visitor sees nothing. Crypt covers installs without SESSION_ENCRYPT, which the Docker setup does not set. - The symbol set leaves out what chat apps turn into formatting and what breaks inside quotes, so a pasted password arrives unchanged. - app.css imports group.css for <x-group>; .ai/rules/views.md records that <x-group> drops data-test and other attributes. - Tests cover the generator, the admin card's saving, validation and example, prefill and generate on the upload page, the flash, and in Chromium Generate and Copy on the upload page and the masked copy on the share page. The admin settings page now has six headed sections. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
a88a052d9a |
Move onto Livewire Material 2.0.0 and leave Tailwind behind
Livewire Material 2.0.0 aligns every component with Material 3 Expressive and carries no Tailwind anywhere, so SealShare drops tailwindcss and its Vite plugin and writes its views in the package's vocabulary: layout components (<x-pane>, <x-stack>, <x-row>, <x-grid>, <x-form>) with M3's spacing tokens, the md-type-*/md-ink-* text classes, and --md-sys-* tokens in its own small stylesheet. - resources/css/app.css opens with the package's layer order, imports foundation.css and the stylesheet of each component the views render, then the scheme, regenerated with the 2025 colour rules at M3's three contrast levels. The app's own rules follow, one section per view, on tokens and on M3's breakpoints (600/840/1200/1600px) only. - Every view is rewritten in that vocabulary while SealShare keeps the shape it had: the admin table, the admin settings, the recovery codes, the share options and the download page are cards, and their fields fill them rather than stopping at the 40rem bound a card already bounds. The user settings pages became cards too, to match the admin's, each with the sections that stand apart from its one subject — deleting the account, the recovery codes — in a card beside it. Material 3 decides how a component behaves, not whether a container survives: buttons keep their label's width, a form's actions end it, and each heading level keeps one type role. - The layouts clear the floating toolbar by the --material-bottom-toolbar the package publishes, and the snackbar clears it by itself. - The two-factor setup QR code comes from QrCodeService, so it keeps a white field and quiet zone in the dark theme and still scans. - Browse Files is a real button that opens the file input, reachable and visibly focused from the keyboard. - Tests: the design test scans views, JS, CSS and app/ and checks the CSS entry both ways (no missing, no unused import). New Chromium suites cover the frame, settings and admin, the share flow, and every page at M3's breakpoint edges (599/600, 839/840, 1199/1200, 1600px). The package's renamed data-md-* hooks replace the 1.x ones. - Boost's update brings the material-3 guideline and skill and drops the Tailwind skill. composer.json requires nonameweb/livewire-material ^2.0 from the Gitea repository, resolved at the 2.0.0 tag. The CHANGELOG records the move as 2.1.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
21bea9646d |
Let the admin choose one of eight colour profiles
Indigo (the default), Blue, Teal, Green, Amber, Rose and Violet in the Vibrant style and Graphite in the Neutral style are generated from config into the stylesheet. Admin settings opens with a colour profile card: a swatch previews the profile on the page, and Save Settings stores it as color_profile, which AppServiceProvider hands to the package's resolver, so every page, mail and error page wears it. An unknown profile is refused, and a saved one that disappears falls back to indigo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9NnLxnPp8vaaurb3Z1MFy |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
1352533667 |
Offer a new share as a QR code and through the share sheet
The share created page gets "Show QR code", a dialog with the link as a QR code (black on white, full screen on a phone) that downloads as a PNG drawn in the browser, with a password reminder for protected shares; and "Share…", which opens the device's share sheet where there is one. Both carry only the link. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9NnLxnPp8vaaurb3Z1MFy |
||
|
Andreas Reinhold / reiniandClaude Opus 5
|
bc69066ead |
Add browser tests for the Material interface
Upload drop zone, copying a share link, unlocking a download on a phone, sorting and deleting on the admin dashboard, and the system theme with the Appearance picker. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9NnLxnPp8vaaurb3Z1MFy |