Hi,
I am trying to deploy DocuSeal to fly.io, but I am getting 422 errors. It’s probably caused by Fly’s reverse proxy. DocuSeal has a solution https://www.docuseal.co/docs/configuring-docuseal-behind-an-existing-reverse-proxy-nginx, but it requires directly modifying nginx config, which I believe is not possible with Fly. Is there another way to work around this issue?
It is definitely possible to run nginx as a reverse proxy on fly machines:
You don’t even need a separate machine to do it, you can add nginx to your existing Dockerfile.
Hi Simon,
If you check e.g. https://debug.fly.dev you’ll see the X-Forwarded-For header is present and it’s correctly set up by the Fly proxy.
Next, if you look carefully at the logs fly logs you’ll notice the actual error is NOT the one in the documentation page you quoted, but rather, this one:
WARN -- : [a67fb670-567c-4167-82c4-5ce18eed9dc4] Can't verify CSRF token authenticity.
Note that Rails requires the SECRET_KEY_BASE value to be set in order to generate and verify CSRF tokens. So the way to fix the 422 error that’s related to CSRF is to set SECRET_KEY_BASE. Docuseal’s docs mention this here. Generate the secret key value as they recommend, and then set it using fly secrets set SECRET_KEY_BASE=value-you-obtained-from-openssl.
Hope this helps!
Regards,
You are right about what the real error is, but unfortunately not about the solution. I tried what you suggested, and getting the same error. Actually all environment variables are optional, and the code has a default if SECRET_KEY_BASE is not set.
Thanks for pointing me to the right direction, it definitely did help, even though the problem is not (yet) resolved!
well - I deployed docubase on my fly.io and got the 422 error, and it went away setting the secret_key_base 
note I deployed using the docuseal docker image:
app = "roadmr-docuseal"
[build]
image = "docuseal/docuseal"
Still, if you see the 422, you can check your logs to see what the actual error logged by the backend is. If that shows nothing relevant, check the developer console in your browser; look at the 422 error response and check the response headers and raw payload, they may contain some clues.
Keep in mind the “422” error is purposefully rather opaque; so while from the frontend perspective it might seem like "the same error’, in the backend it’s probably about something different.
Regards,
Just a shot in the dark… look in config/environments/production.rb for something like config.force_ssl or perhaps config.assume.ssl (it looks like that changed going from Rails 7.0 to 7.1). Try setting that to true.
I had a problem a while back with a Rails application that was deployed behind nginx, and while it would handle get just fine, I got Can't verify CSRF token authenticity on POSTs.
Specifying the image did the trick. I cloned the repo and deployed from there, which should have been the same, but for some reason it wasn’t. Anyway, problem solved, thank you so much!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.