Wiki: bring a picture in from a web address, saved as an upload

claude-bot commented

2026-10-13 19:57:38 +00:00

Collaborator

Owner request, 13 Oct 2026. Not for 4.5.1.

Since #1138 a page's text draws only pictures uploaded to Quest Board; an outside image address in text is shown as a link. The owner wants people to be able to bring a picture in by its address: Quest Board downloads the file once, stores it as an upload, and shows the stored copy. Readers' browsers still never fetch from the outside host, so #1138's protection stands.

What exists

A page's own picture already has "Or from a web address" in the editor (GM only): the server fetches it and stores it (/from-url). The fetch has the SSRF checks, size limit and image validation this needs.
Pictures in page text have no such route: only upload (file picker, paste).

Wanted

In the editor, for pictures in text. Pasting or typing ![alt](https://…) (or a bare image address on its own line), and the picture button, offer "Bring it in": the server downloads it, stores it as a campaign file, and the text is rewritten to the stored address. Until brought in, it stays a link as today.
On import. A campaign or wiki import whose text holds outside image addresses can bring them in, with a count shown first ("12 pictures from 3 sites"), not silently.
Existing pages. A Wiki health row, "Pictures still on other sites", listing pages whose text links an outside image, with "Bring it in" per row (the same shape as #1157's Link it).

Decisions to make

Who may do it. GMs only, or players too where they can edit or suggest? A suggestion that carries a fetch should fetch on acceptance, not on submission.
What the server will fetch. http(s) only; public addresses only (the existing validator: no private, loopback or link-local ranges, redirects re-checked); a size cap (page pictures use one already); content sniffed as an image, re-encoded or stripped of metadata; SVG refused or sanitised; a per-campaign and per-user rate limit so the server cannot be used to hammer another site.
Where it is stored and what it costs. Campaign files count toward retention, export size and, for the hosted service, a plan's storage; show the size before saving.
Provenance. Keep the source address and the fetch time on the stored file (shown to GMs), so a picture can be traced and a takedown answered. Whether to show a credit line under the picture.
Failure wording. The site refused, the file is not a picture, it is too large, the address is not reachable from the server (the same point the content-pack address hint makes).
Rights. One line in the editor that bringing a picture in copies it to this server; no gate.

Notes

The backend never fetches on behalf of a reader: only on an explicit action by someone allowed to add pictures.
Reuse the /from-url fetcher; do not write a second one.
Bot, emails and exports already use stored files; nothing changes there.

Owner request, 13 Oct 2026. Not for 4.5.1. Since #1138 a page's text draws only pictures uploaded to Quest Board; an outside image address in text is shown as a link. The owner wants people to be able to bring a picture in by its address: Quest Board downloads the file once, stores it as an upload, and shows the stored copy. Readers' browsers still never fetch from the outside host, so #1138's protection stands. ## What exists - A page's own picture already has "Or from a web address" in the editor (GM only): the server fetches it and stores it (`/from-url`). The fetch has the SSRF checks, size limit and image validation this needs. - Pictures in page *text* have no such route: only upload (file picker, paste). ## Wanted 1. **In the editor, for pictures in text.** Pasting or typing `![alt](https://…)` (or a bare image address on its own line), and the picture button, offer "Bring it in": the server downloads it, stores it as a campaign file, and the text is rewritten to the stored address. Until brought in, it stays a link as today. 2. **On import.** A campaign or wiki import whose text holds outside image addresses can bring them in, with a count shown first ("12 pictures from 3 sites"), not silently. 3. **Existing pages.** A Wiki health row, "Pictures still on other sites", listing pages whose text links an outside image, with "Bring it in" per row (the same shape as #1157's Link it). ## Decisions to make - **Who may do it.** GMs only, or players too where they can edit or suggest? A suggestion that carries a fetch should fetch on acceptance, not on submission. - **What the server will fetch.** http(s) only; public addresses only (the existing validator: no private, loopback or link-local ranges, redirects re-checked); a size cap (page pictures use one already); content sniffed as an image, re-encoded or stripped of metadata; SVG refused or sanitised; a per-campaign and per-user rate limit so the server cannot be used to hammer another site. - **Where it is stored and what it costs.** Campaign files count toward retention, export size and, for the hosted service, a plan's storage; show the size before saving. - **Provenance.** Keep the source address and the fetch time on the stored file (shown to GMs), so a picture can be traced and a takedown answered. Whether to show a credit line under the picture. - **Failure wording.** The site refused, the file is not a picture, it is too large, the address is not reachable from the server (the same point the content-pack address hint makes). - **Rights.** One line in the editor that bringing a picture in copies it to this server; no gate. ## Notes - The backend never fetches on behalf of a reader: only on an explicit action by someone allowed to add pictures. - Reuse the `/from-url` fetcher; do not write a second one. - Bot, emails and exports already use stored files; nothing changes there.

claude-bot commented

2026-10-13 20:00:39 +00:00

Author

Collaborator

Owner decisions, 13 Oct 2026:

Who may bring a picture in: anyone who can edit the page.
Source address: kept on the stored file. Not shown to everyone; shown to GMs and admins.
Storage: downloaded pictures count toward a campaign's storage like any upload.
New: a campaign owner can restrict who may add media (uploads and downloaded pictures alike). A campaign setting, e.g. "Who can add pictures and files": everyone who can edit (default), GMs only. Enforced on every upload route and on the bring-it-in route, not only in the UI.

New, from the owner's question: there is no page that lists a campaign's stored files. Files are reachable only from the page they are on. Add one:

Campaign → Settings → Files (GMs): every stored picture, map image, handout and attachment, with the page it is on, who added it and when, its size, its source address if it was downloaded, and whether anything still uses it. Remove from there (with the page's text shown, since removing breaks it). Total against the campaign's storage.
Admin → Files (admins): the same across campaigns, by size, for a server running short of disk.
Orphans (a stored file no page refers to any more) are listed separately so they can be cleared.

File types as they are today, for reference: pictures are JPEG, PNG, WebP and GIF (re-encoded, metadata stripped, 8 MB); map images the same types up to 75 MB; attachments are those plus PDF and plain text (8 MB). No SVG, no audio or video, no office documents. Downloading by address should accept exactly the picture types, nothing more.

Owner decisions, 13 Oct 2026: - **Who may bring a picture in:** anyone who can edit the page. - **Source address:** kept on the stored file. Not shown to everyone; shown to GMs and admins. - **Storage:** downloaded pictures count toward a campaign's storage like any upload. - **New: a campaign owner can restrict who may add media** (uploads and downloaded pictures alike). A campaign setting, e.g. "Who can add pictures and files": everyone who can edit (default), GMs only. Enforced on every upload route and on the bring-it-in route, not only in the UI. **New, from the owner's question: there is no page that lists a campaign's stored files.** Files are reachable only from the page they are on. Add one: - **Campaign → Settings → Files** (GMs): every stored picture, map image, handout and attachment, with the page it is on, who added it and when, its size, its source address if it was downloaded, and whether anything still uses it. Remove from there (with the page's text shown, since removing breaks it). Total against the campaign's storage. - **Admin → Files** (admins): the same across campaigns, by size, for a server running short of disk. - Orphans (a stored file no page refers to any more) are listed separately so they can be cleared. File types as they are today, for reference: pictures are JPEG, PNG, WebP and GIF (re-encoded, metadata stripped, 8 MB); map images the same types up to 75 MB; attachments are those plus PDF and plain text (8 MB). No SVG, no audio or video, no office documents. Downloading by address should accept exactly the picture types, nothing more.

claude-bot commented

2026-10-13 20:38:47 +00:00

Author

Collaborator

Owner, 13 Oct 2026: the files pages must let a GM, and an admin, preview and view every stored file, not only list it.

Preview in the list: a thumbnail for pictures and map images (maps from their smallest tile level, never the 75 MB original); the first page for a PDF; the first lines for plain text; a type icon for anything that cannot be drawn.
View: open the file at full size from the list: pictures and maps in a viewer with zoom, PDFs and text through the existing authenticated download route. A grid view and a table view, since a GM reviewing pictures wants to see them and an admin chasing disk wants sizes.
Filter and sort: by kind, by who added it, by page, downloaded from an address or uploaded, unused; by size and by date.
Serving: previews and views go through the same authenticated, non-cacheable route as today (X-Accel-Redirect from private/), with thumbnails generated and stored once, not by a public URL. The img-src 'self' rule from #1138 stays as it is.
Admin access is new access and should be deliberate. An admin does not see a campaign's content today unless they are a member. A page that shows every campaign's pictures and handouts to an admin is a real widening: record each view of another campaign's file in the audit log, say so on the page, and state it in the Privacy page's "who can see what". For the hosted service this needs to be in the terms. Decide whether an admin sees previews by default or sees the list (sizes, owners, addresses) and opens a file as an audited act.
GM-only and hidden content: a GM sees everything in their campaign, including files on GM-only pages and unrevealed handouts. Nothing here is shown to players.

Owner, 13 Oct 2026: the files pages must let a GM, and an admin, **preview and view every stored file**, not only list it. - **Preview in the list:** a thumbnail for pictures and map images (maps from their smallest tile level, never the 75 MB original); the first page for a PDF; the first lines for plain text; a type icon for anything that cannot be drawn. - **View:** open the file at full size from the list: pictures and maps in a viewer with zoom, PDFs and text through the existing authenticated download route. A grid view and a table view, since a GM reviewing pictures wants to see them and an admin chasing disk wants sizes. - **Filter and sort:** by kind, by who added it, by page, downloaded from an address or uploaded, unused; by size and by date. - **Serving:** previews and views go through the same authenticated, non-cacheable route as today (`X-Accel-Redirect` from `private/`), with thumbnails generated and stored once, not by a public URL. The `img-src 'self'` rule from #1138 stays as it is. - **Admin access is new access and should be deliberate.** An admin does not see a campaign's content today unless they are a member. A page that shows every campaign's pictures and handouts to an admin is a real widening: record each view of another campaign's file in the audit log, say so on the page, and state it in the Privacy page's "who can see what". For the hosted service this needs to be in the terms. Decide whether an admin sees previews by default or sees the list (sizes, owners, addresses) and opens a file as an audited act. - **GM-only and hidden content:** a GM sees everything in their campaign, including files on GM-only pages and unrevealed handouts. Nothing here is shown to players.

claude-bot commented

2026-10-17 03:26:46 +00:00

Author

Collaborator

The open question here (whether an admin sees previews of another campaign's files or only the list, with opening a file as an audited act) is now Q181 on the owner's Questions page. Recommended: list only by default, each open audited.

The open question here (whether an admin sees previews of another campaign's files or only the list, with opening a file as an audited act) is now **Q181** on the owner's Questions page. Recommended: list only by default, each open audited.

claude-bot commented

2026-10-17 03:37:39 +00:00

Author

Collaborator

Owner's answer, Q181 (17 Oct 2026): (a). By default Admin → Files shows the list only: size, campaign, who added the file, and its source address if it was downloaded. Opening or previewing another campaign's file is a deliberate act and is written to the audit log. The page says so, and the Privacy page's "who can see what" states it. A GM keeps full previews within their own campaign. With this, nothing on #1181 is waiting on a decision.

**Owner's answer, Q181 (17 Oct 2026): (a).** By default Admin → Files shows the list only: size, campaign, who added the file, and its source address if it was downloaded. Opening or previewing another campaign's file is a deliberate act and is written to the audit log. The page says so, and the Privacy page's "who can see what" states it. A GM keeps full previews within their own campaign. With this, nothing on #1181 is waiting on a decision.

claude-bot referenced this issue

2026-10-17 03:40:32 +00:00

[Design] Hosted Quest Board: GM plans with campaign slots, AI usage pricing, and an entitlements layer #642

claude-bot added this to the v4.6.0 - Calendar, Templates & Table Tools milestone

2026-10-17 04:21:24 +00:00