satori

Problem (#780) is a standard value of both and , but passing it throws: Root cause Two value maps in omit it, so rejects the value. Yoga itself already implements it: and both exist and were simply never mapped. Fix One entry per map: Tests asserts positions rather than an image snapshot, because position is exactly what distinguishes this value from the one people reach for as a workaround. Two 10px boxes in a 100px column: Measured against this branch, not assumed. Reverting the two lines makes both tests fail with the two "Invalid value" errors quoted above. , and still pass (26 tests). Notes The change is additive: no existing value changes meaning, and the default ( / ) is untouched.

Bug report Description / Observed Behavior Setting throws instead of rendering: The value map in has five entries and is not one of them, so (the helper in the bundle) rejects it. The underlying layout engine already supports it. Verified against the shipped bundle of : So both Yoga constants are present in the bundle; they are simply never mapped. has the same gap: its map covers , while exists and is unreachable. Expected Behavior is a standard value of both and , and Yoga implements it. I would expect Satori to accept it and distribute the free space evenly, including before the first and after the last item. Reproduction The playground share link encodes the editor state, so here is the minimal input to paste instead: Swapping for renders; throws. Additional Context satori 0.29.0, Node 26. Searching the issue tracker for returns no results, so this does not appear to have been reported before. Practical impact: distributing N items evenly over a fixed height is common in generated cards. The workaround is , which is not the same distribution (half-size gaps at the edges), or inserting spacer nodes.

Satori 0.29.0 added SSRF protection for server-side image fetching in #769. Thank you for addressing this security risk. Unfortunately, the new protection unconditionally blocks , with no supported way for an application to opt out, allow a trusted host, or provide its own fetch implementation. This prevents us from upgrading from 0.28.1. Our application uses Satori to generate Open Graph images. In local development, application assets are served by our local development server: After upgrading to 0.29.0, local rendering fails with: These are trusted, repository-owned static assets served by our local development environment. The same code uses a public HTTPS asset origin in production. Impact This breaks all local development and testing of the affected Open Graph image-rendering paths. Developers can no longer accurately test these images using the same local application and asset server used by the rest of the project. Because there is no supported escape hatch, our current choices are to: remain on Satori 0.28.1; patch Satori locally; rewrite our image-loading pipeline; or configure local development to fetch assets from a remote deployment, which means developers are no longer testing their local assets. We do not want to remove SSRF protection in production, and we would not enable any reduced-security behavior there. We only need an explicit way to support trusted private destinations in a controlled local environment. Possible solutions We would be happy with any API that preserves the secure default while allowing the embedding application to make an explicit, local-only decision. 1. Per-render private-network opt-out For example: The option should default to , with documentation explaining that it must only be enabled when all image sources are trusted. A narrower variation could permit loopback without permitting every private network: 2. Per-image-request allow callback A callback would let applications make a more targeted decision: Satori could continue applying its normal protection unless the callback explicitly permits the individual URL. This could also be expressed as an allowlist: A callback is more flexible, but either form would let us authorize only the local asset server rather than disabling the checker entirely. 3. Pluggable image fetcher The initial version of #769 included a custom fetcher, but it was removed because a signature would allow caller-controlled and redirect behavior and would not compose safely with hardened fetch libraries. A narrower signature could avoid that concern: Satori would provide only the URL string, leaving redirect policy and network enforcement entirely to the application-supplied implementation. Our application already has a hardened server-side fetch implementation that: blocks private, loopback, link-local, and reserved addresses in deployed environments; validates resolved addresses at connection time; applies the same protection to redirects; and explicitly permits private destinations only in the local environment. Allowing us to provide that implementation would both restore local development and provide stronger production protection than a literal-host check alone. An image resolver returning data rather than a could be another option: Security expectations We are not requesting that localhost be allowed by default. Any escape hatch could: retain the current secure behavior by default; require an explicit, prominently named option; document the SSRF consequences; be configured independently for each Satori render; and allow applications to keep the protection enabled in production. In our case, reduced protection would only be enabled in local development. Production uses public HTTPS asset origins and would continue using SSRF enforcement or our application’s hardened fetcher.