9 Commits

Author	SHA1	Message	Date
Darko Gjorgjijoski	00c9c4268e	fix(pdf): give the reports their margin back, and one shared chrome (#738) ... * fix(pdf): put the page margin back on the report PDFs The report templates carry no inset of their own. They set `.sub-container { padding: 0px 20px }` and nothing else, and relied entirely on dompdf's built-in 1.2cm page margin. #727 made DompdfDriver always inject an `@page` rule from PdfPageSetup, and #735 defaulted those margins to zero so invoice2 and estimate2 could bleed their header band to the paper edge. The document templates were fine, they carry their own 30px/50px insets. The reports were not: every one of them now renders flush against the paper, with the company name's glyph box actually clipped 1.2pt above the top edge. The zero default has to stay for documents, so reports get a margin of their own: `pdf.page.report_margin`, PDF_REPORT_MARGIN, defaulting to the 1.2cm they were drawn against. It is a separate key on purpose, so an operator tuning the document margins for their invoice template does not silently reflow every report as a side effect. A page margin rather than padding on the templates because reports run to several pages and padding only insets the first one. Sales by customer already spans two on the demo data, and page two moves with the rest. Plumbed as an optional PdfPageSetup on the driver contract, defaulting to the configured page, so every existing call site renders exactly as before and only the five report controllers ask for anything different. Measured on the five reports, page 595.28 x 841.89pt, 1.2cm = 34.02pt: first page ink moves from xMin 15.0-15.8 / yMin -1.2 to xMin 49.0-49.8 / yMin 32.8, every axis shifting by exactly the margin. Also fixes three untranslated keys this exposed: the expenses report printed its column headings as the literal strings "expenses.date", "expenses.note" and "expenses.amount", which have never existed in lang/en.json. They are now pdf_expense_{date,note,amount}_label, and a test pins that every translation key a report template uses resolves in English. * fix(pdf): put the minus sign in front of the currency symbol format_money_pdf() formatted the signed value and then concatenated the symbol, so a negative amount came out as "$-24,738.00". Credit notes made that common: every line on a credit note PDF reads negative, and one credit note in a period is enough to make the customer sales report show a negative total. The magnitude is formatted first now and a single minus is prefixed to the whole assembled string, so the sign leads and the symbol stays glued to the digits. Only the symbol-first branch changes. number_format() already put the sign in front of the digits, so a trailing-symbol currency read "-24,738.00$" before and is byte-identical after. The sign is decided on the formatted digits rather than on the raw input, so an amount that rounds away at the currency's precision renders as zero rather than as "-0". A stray cent on a zero-precision currency is the case that needs it. * refactor(pdf): one shared chrome for the report PDFs The five report templates were five drifted copies of one 2018 stylesheet, and the insets had stopped agreeing with each other. profit-loss alone put its header and income row at +20px, its "Expenses" heading at +23px, its category rows at +30px, and its total rule and NET PROFIT band at +0, because that markup sat outside the container everything above it was in. Four left edges on one page. Every report also carried the same self-cancelling total rule, where `padding: 0px` follows the two longhands it silently overrides, and expenses carried six rule blocks nothing referenced at all, including the only horizontal rule in the file. There is now one layout partial and one stylesheet, and each report is content only: 236 lines down to 47 for profit-loss, and about 1200 lines deleted across the five. One content edge, measured: every band starts at 34.016pt and every amount ends at 561.260pt, on every page of every report. What changed on the page: - Real tables with a thead, so column headings repeat across page breaks. Only expenses had headings before and none of them used thead. sales-items emitted a separate table per item, which is why its rows never lined up. - The company logo in the header, the same fallback-to-name pattern the document templates use. - An empty period renders a "no records" row. profit-loss, sales-items and tax-summary rendered their total row and rule unconditionally, so a month with no data showed a heading, a gap, a rule and a lone $0.00. - Sections stay whole across a page break where they fit, and a section heading never sits at the foot of a page with its rows overleaf. - Credit notes stay in the sales totals, since a reversal netting the sale out is correct, but the line is tagged so a CN- number is not read as a sale. It reuses the document's own label, which is already in the shipped locales. - Labels stopped carrying their own presentation: "TOTAL EXPENSE" (also singular) is "Total expenses" and the stylesheet does the uppercasing. The five controllers drop the dead colour-settings block: nine *_color settings were queried and shared by every report, no template ever read them, and no migration, seeder or UI ever wrote them, so the query always returned an empty collection. Every other shared variable name is untouched, because a custom report template is a copy that references them by name. make:template had to learn the same lesson: it only ever copied partials/table.blade.php, so a cloned report would extend a layout that does not exist in its namespace and die on render. It now copies every partial a type ships and rewrites references by view name, including partial-to-partial ones, so each custom template still gets its own copies.	2026-08-02 14:34:02 +02:00
Darko Gjorgjijoski	35a248b48b	fix(pdf): send the installed fonts to Gotenberg (#733) ... FontService writes absolute host paths into the @font-face rules: src: url("/var/www/html/storage/fonts/NotoSansSC-Regular.ttf") dompdf shares that filesystem so they resolve. Chromium runs inside the Gotenberg container and cannot see any of it, so every installed font package silently failed to load and documents fell back to whatever fonts that image happens to ship. The docs recommend Gotenberg specifically for mixed-script documents, which made this exactly the wrong way round -- it worked only by accident, because Chromium's own font set covers more than dompdf's single-font behaviour. The font files now travel with the document as Gotenberg assets, and the rules are rewritten to name them. Gotenberg unpacks assets next to index.html, so a bare filename resolves. Only fonts the markup actually references are sent. A CJK package is several megabytes and has no business riding along on a request that never mentions it. Confirmed against a stock gotenberg:8, reading the fonts back out of the rendered PDF: before AAAAAA+LiberationSerif (Gotenberg's fallback) after AAAAAA+NotoSans-Regular (the app's own font) Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 14:41:35 +02:00
Darko Gjorgjijoski	773670c18f	feat(pdf): archival PDF/A output and document properties (#732) ... Generated files carried no document properties at all, so an archive of them showed a column of blank titles and no author. Title, Subject, Author and Creator are now written from the document number and company, on both drivers: dompdf via addInfo(), Gotenberg via metadata(). dompdf needed more than the API call. It reads Title from the <title> element during render(), which happens after addInfo(), so metadata set through the API alone was silently overwritten by whatever the template put there and the two drivers disagreed about what the file was called. The title is written into the markup as well, escaped. Also adds an archival format setting for Gotenberg: off, PDF/A-1b, -2b or -3b. PDF/A-3 is what the EU e-invoicing formats expect. Verified against a stock gotenberg:8 -- LibreOffice inside the image does the conversion and the output carries the right pdfaid:part in its XMP -- so no extra components are needed. A fixed list rather than free text, because the SDK forwards whatever it is given and an unsupported value would surface only as an HTTP error from the service at render time. Empty is a real choice meaning an ordinary PDF, so it overrides an env default rather than falling through it. Gotenberg only: dompdf cannot produce PDF/A. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 14:37:22 +02:00
Darko Gjorgjijoski	713e0bc2e8	feat(pdf): repeating page headers and footers, and page numbers (#729) ... Takes over #690 by csoscd. The companion-view idea is theirs; this reworks it onto the shared page setup and fills in the gaps that stopped it landing. A `{template}_header` or `{template}_footer` view next to a template is rendered alongside it and repeated by Chromium on every page. The suffix resolves through the pdf_templates:: namespace too, so custom templates get it with no extra wiring. Two things had to change for that to be useful. Companion views are now hidden from the template picker. getFormattedTemplates() lists every .blade.php it finds, so an invoice1_footer would otherwise appear as a separately selectable template with no preview image -- the feature would have introduced that the moment anyone used it. And it does something out of the box. #690 shipped no companion views, so both of its margin settings were visible no-ops until someone hand-wrote a Blade file. Instead there is a pdf_page_numbers setting, off by default, that supplies a footer when a template has none. A template's own companion still wins, so turning page numbers on cannot overwrite a designed footer. The setting sits under Gotenberg because only Chromium can repeat a footer; dompdf has no equivalent. Its value is still carried by the dompdf form so saving from there cannot clear the choice -- the field is absent from that payload, and the controller only writes it when present. Margins come from the page setup rather than #690's separate header_margin and footer_margin. Chromium draws header and footer inside the page margin, so the existing margins are the space they occupy; two more settings for the same distance would have been a second way to say the same thing. Verified against a live gotenberg:8 on a two-page document: off produces no footer, on produces "1/2" and "2/2" on the respective pages, and a companion footer replaces both. #690's own test is not carried over. It asserted nothing: a bare View::shouldReceive('exists') is an allowance rather than an expectation, andReturn(false) never entered the companion branch, and the call sat inside try { } catch (Throwable) { }, so it passed with the feature deleted. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:52:47 +02:00
Darko Gjorgjijoski	a54a5ee007	feat(pdf): one page setup, honoured by both drivers (#728) ... Paper size was a Gotenberg-only setting stored as a single "210mm 297mm" string. dompdf had no page settings at all: size was pinned to config/dompdf.php's fixed 'a4', its top-level `orientation` key was read by nothing (the installed barryvdh v3 builds options only from `defines`), and margins were whatever dompdf's own stylesheet said. So the two drivers disagreed about margins by default -- dompdf 1.2cm, Gotenberg hardcoded to zero -- and selecting dompdf silently discarded the paper size. Replaces gotenberg_papersize with pdf_paper_width / pdf_paper_height / pdf_orientation / pdf_margin_{top,right,bottom,left}, saved and applied for either driver. Width and height are separate CSS lengths because that is the only lossless shared notation: Gotenberg has no named sizes, and dompdf's named table cannot express everything Gotenberg accepts. Named presets (A3/A4/A5/ Letter/Legal) are a convenience in the UI that resolve to a pair of lengths. PdfPageSetup resolves it once and translates: a points array plus an orientation argument for dompdf, CSS lengths plus landscape() for Gotenberg. Both are handed the portrait pair, since each swaps the axes itself. Gotenberg's margins() takes top, bottom, left, right, which is not the CSS order. dompdf exposes no margin API, so DompdfDriver injects an @page rule -- at the top of <head>, so a template declaring its own still wins. Doing it in the driver rather than a Blade partial means custom templates get it without including anything. Margins default to 1.2cm, dompdf's existing default, so Gotenberg starts matching it rather than rendering edge-to-edge. Verified against a live gotenberg:8: A4 portrait, A4 landscape and Letter at zero margins all come out with the same page box and the same ink offsets on both drivers. A malformed length now throws rather than being ignored. Blank still falls back, but a value that is set and wrong is an operator mistake, and the drivers would otherwise fail differently: dompdf throws converting to points, Gotenberg would forward the string and render at some other size. Also here: - Migration splits an existing gotenberg_papersize into the new pair. It earns its place because that key ships in 2.x, not just a 3.x alpha, so a stable install that chose Letter would otherwise come back up on A4. Drops gotenberg_margins, which 2.x also stores and neither driver ever read. - Removes EnvironmentManager::savePDFVariables/getPDFConfiguration, which had no caller anywhere, and the unused EnvironmentManager injection in the controller. - config/dompdf.php: drops the dead `orientation` key and defaults enable_remote to false, matching .env.example, which sets it explicitly and explains why. Installs predating that line were falling back to true. - Retires the settings.pdf.footer_text and pdf_layout strings, which no component referenced. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:48:51 +02:00
Darko Gjorgjijoski	6cb754da60	fix(pdf): give both drivers one contract, and fix what that was hiding (#727) ... PdfDriver and ResponseStream existed but nothing implemented them. The factory returned the vendor dompdf wrapper for one driver and a bespoke class for the other, so the two were never held to the same shape. Three things had slipped through that gap. Report PDFs answered 403 for everyone. The five report routes carry no company header, so ScopeBouncer is not in their middleware stack and the ability scope was never set; 'view-financial-reports' is stored scoped to a company, so the check could not pass. They now scope to the company named in the URL. The policy still checks membership, so this grants nothing new. Also firstOrFail() on the hash lookup, so an unknown company is a 404 rather than a 500 on a null. Report downloads were fatal on Gotenberg. GotenbergPdfResponse had no download(), and the report controllers are its only callers. Added, alongside stream() and output(), with the whole set now on the interface. Streamed documents carried an HTTP preamble. GeneratesPdfTrait wrapped $pdf->stream() -- already a Response -- in another response()->make(), which stringified it and prepended "HTTP/1.0 200 OK" plus headers to the file. Readers scan the first kilobyte for %PDF so nobody noticed, but the bytes were malformed. Passing ->output() fixes it, and the render test now asserts the position. Two driver-parity settings, both checked against a real gotenberg:8 rather than inferred: emulateScreenMediaType(), because Chromium defaults to print media while config/dompdf.php renders as screen, so a @media print rule applied on one driver and not the other; and printBackground(), which turns out to affect only the root background, since Chromium paints element backgrounds either way. No stock template sets a body background, so that one changes nothing today and is here to keep custom templates consistent across drivers. Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF	2026-08-01 12:43:31 +02:00
csoscd	f8cfb6cd33	fix: allow Gotenberg to reach private/Docker-internal hosts (#691) ... * fix: allow Gotenberg to reach private/Docker-internal hosts (Issue #688) The SSRF guard introduced in #664/#671 correctly blocks arbitrary private URLs, but also prevents legitimate use-cases where Gotenberg runs alongside InvoiceShelf in a Docker Compose network (e.g. the default http://pdf:3000 service name resolves to a private IP). Add a `gotenberg_allow_private_host` setting (env: GOTENBERG_ALLOW_PRIVATE_HOST, default false) that: - skips PrivateNetworkGuard in GotenbergPdfDriver - skips PublicHttpUrl validation in PDFConfigurationRequest - exposes a clearly-warned toggle in the admin PDF settings UI - is persisted to the settings table and loaded via AppConfigProvider A disabled guard is safe for controlled private networks (Docker Compose, LAN); it must never be enabled for untrusted hosts. The UI surfaces a prominent warning to communicate this constraint. Closes #688 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * refactor(gotenberg): scope the private-host exemption to a declared host Reshapes the escape hatch from a boolean admin setting into an environment-declared host allowlist. The driver streams the upstream response body back as the PDF, so a mis-set Gotenberg host is full-response SSRF — pointed at a link-local metadata endpoint it returns cloud credentials. A blanket "allow private" switch left that reachable: gotenberg_host stays editable from the admin UI, so any install that enabled the switch to run a sidecar could have the host repointed at an internal service. The population the flag existed to serve was exactly the population it failed to protect. GOTENBERG_ALLOWED_PRIVATE_HOST now names the single host that may skip the guard. Only that exact value is exempt; every other private target stays blocked. GotenbergHostPolicy owns the comparison so the save-time rule and the runtime driver guard cannot drift, and normalises case, trailing slash and surrounding whitespace on both sides. Being env-only also drops the settings-table key, the AppConfigProvider branch and the whole admin UI surface — the toggle there could not be switched on in any case, since BaseSwitchSection has no slot and was passed no v-model, so the child BaseSwitch was discarded and the value never changed from false. Restores the gotenberg_margins validation rule, which the previous revision replaced rather than added alongside. Tests cover both directions, including that declaring one private host does not exempt another; sabotaging the policy to always exempt fails 16 of the 22. Co-authored-by: csoscd <csoscd@users.noreply.github.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Darko Gjorgjijoski <dg@darkog.com> Co-authored-by: csoscd <csoscd@users.noreply.github.com>	2026-07-29 10:57:52 +02:00
Darko Gjorgjijoski	99ea898e88	fix(security): block SSRF via the Gotenberg host setting (GHSA-mfxg) (#671) ... v3 port. The Gotenberg PDF driver was missed when the SSRF guards were added to the AI, exchange-rate and file-disk drivers: gotenberg_host was validated only with 'url', and the driver POSTs the rendered HTML to it. Reuses the existing infrastructure (consistency with the other drivers): - Wires App\Rules\PublicHttpUrl into the gotenberg_host validation rule. - Adds PrivateNetworkGuard::assertAllowed() in GotenbergPdfDriver before the outbound call (covers env/seed/stale config + DNS rebinding). Adds a unit test asserting the gotenberg_host rule rejects private/loopback/ link-local addresses and allows a public one.	2026-06-12 11:02:19 +02:00
Darko Gjorgjijoski	f657b53215	refactor(services): split driver infrastructure out of Services into Support ... Services/Integrations/ExchangeRate/ and Services/Pdf/ were both mostly Support-shaped: interfaces, abstract classes, static factories, concrete adapter drivers, DTOs, and exceptions — infrastructure that doesn't carry business logic. They only each had one real DI-injected service mixed in. This commit applies the same Services=DI-business-logic / Support=stateless-plumbing rule we've been using throughout the reorg: **Moved to Support/Integrations/ExchangeRate/** (7 files): ExchangeRateDriver (abstract), ExchangeRateDriverFactory (static), ExchangeRateException, and the four concrete drivers (CurrencyConverter, CurrencyFreak, CurrencyLayer, OpenExchangeRate). These are HTTP adapters over third-party currency APIs — same shape as the Hashids library wrapper classes already in Support. **Moved to Support/Pdf/** (6 files, merging with existing Pdf utilities): PdfDriver (interface), PdfDriverFactory (static), PdfService (static facade), GotenbergPdfDriver, GotenbergPdfResponse (DTO), ResponseStream (interface). The Support/Pdf/ dir now contains the full PDF rendering subsystem — drivers + sanitizer + template/image utilities. **Promoted to Services/ root** (the real DI services): ExchangeRateProviderService (CRUD for ExchangeRateProvider model) and FontService (font package install/download orchestration). Both are proper DI services — instance methods, model writes, HTTP side effects. Services/Integrations/ and Services/Pdf/ are now empty and deleted. Services/ holds only DI-injected classes; Support/ holds all the plumbing. 17 files renamed (git detects 90-99% similarity), 4 consumer files updated (DriverRegistryProvider, PdfServiceProvider, ExchangeRateProviderController, FontController, GeneratesPdfTrait, test). 350 tests pass, Pint clean.	2026-04-11 16:30:00 +02:00