Where to put temporary files when deploying?

Questions / Help
,
1

I have a simple LiveView app that

  1. write user input to a temporary markup file (content.typ),
  2. drops to System.cmd/2 to process this markup with a CLI (typst), and
  3. deliver the output (content.png) to the client

In dev, I specify the path for the temporary files as

Application.app_dir(:typeset, "priv/static/uploads/")

and this works on my machine™.

I then have this dockerized and deployed on Fly, copying the Typst CLI to /bin and verified the CLI works by ssh in.

However, the temp files are now written to a directory that does not exist.

** (File.Error) could not write to file "/app/_build/prod/lib/typeset/priv/static/uploads/content.typ"

What is the proper way of handling temporary files, to be processed with a CLI, when deploying?

2

https://hexdocs.pm/elixir/System.html#tmp_dir/0

6 Likes
3

Thank you @LostKobrakai.

For future readers: you’d use System.tmp_dir/0 for the path. So if you want to write a content.png, it would go to

File.write!(
  System.tmp_dir() <> "/content.png",
  your_content_here
)

You can tell Phoenix to serve these as static files by adding a plug in MyAppWeb.Endpoint immediately after the only Plug.Static:

plug Plug.Static,
  at: "/",
  from: :my_app,
  gzip: false,
  only: MyAppWeb.static_paths()

# 👇 ADD THIS
plug Plug.Static,
  at: System.tmp_dir(),
  from: System.tmp_dir()
2 Likes
4

Giving people access to all your system tmp files is not a good idea. You want to scope this to a nested folder for your application.

6 Likes
5

This is a follow-up question on static files.

I have now deployed the little LiveView (on Fly: Typeset · Phoenix Framework) and on its own it’s all dandy. The plan was to make this into an iFrame embed in Wordpress, so this follows the recipe How to: Embed a LiveView via iframe and goes through its own pipeline.

I mapped this to a custom domain: Typeset · Phoenix Framework and the same app falls apart with this error:

Cookie “__phoenix_reload_status__” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

__phoenix_reload_status__ is part of Phoenix.LiveView.Static, but I don’t understand why this is causing an issue only when it’s visited on the custom domain. There is a separate socket with its own @session_options

  @embed_session_options [
    store: :cookie,
    key: "_typeset_key",
    signing_salt: "xxxxxxx",
    same_site: "None; Secure"
  ]

and this should be very permissive?

EDIT: this is about check_origin, related to: Phoenix LiveView constantly refreshes with custom domain - Phoenix - Fly.io

6

I am also using Typst in a couple of projects, that’s why I assembled a Hex package that uses a Rust nif so you don’t have to shell out, or use a temporary file.

7

Is the rust API you are using public?

From the documentation it seems like typst was designed as a self-contained product rather than a rust library (even if implemented in rust).

8
1 Like
9

Thanks — I did check out ex_typst. I shell out (necessitating the temporary file) because I’m using the CLI to generate transparent PNGs, and also (in the future) use typst query from the CLI to extract parameters from the run.

(It was a while since I did the earlier expts; with the PDF, the only way I can get a clean transparent PNG back out was to Mogrify it with peculiar flags… again from the CLI.)

10

:+1:

Each case is different.