Invalid authenticity token when deploying a Rails app with Machines

1

I have an app running without any issues on Apps v1 and I’m now trying to migrate it to Machines API. deploy is working fine, app opens without issues but I can’t do any POST request, I keep getting this error

2022-12-29T15:40:24.312 app[568300dcdd458e] gru [info] [3de15b8c-2490-478c-8ddb-f72cc8ad12fb] HTTP Origin header (https://xxxx.fly.dev) didn't match request.base_url (http://xxx.fly.dev)

for some reason, request.base_url is suffixed with http while the header has https. not really sure how to fix this since all I found on Google tells me to update Nginx config files but, well…

I suspected it could be some CORS config thing but my configuration has nothing special

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins "*"

    resource "/assets/*",
             headers: :any,
             methods: %i[get head options]
  end
end

has anyone seen something like this?

2

I tried a brand new deploy and I still see this error

2022-12-31T02:52:59.836 app[908011ec113287] gru [info] [8ee13eb4-7b3f-4dde-a08e-411c851494ad] ActionController::InvalidAuthenticityToken (HTTP Origin header (https://sumiu-machine.fly.dev) didn't match request.base_url (http://sumiu-machine.fly.dev)):

it happens only with Machines, good old Nomad doesn’t trigger this error.

3

I have a Rails 7 app that I migrated to machines without any problems. But perhaps the fact that I had the following in my config/environments/production.rb was the reason why:

config.force_ssl = true

The reason why I have this in my config is unrelated to fly, but rather due to how I originally had my app set up - with an apache httpd reverse proxy.

4

hmm, just added it and now I get ERR_TOO_MANY_REDIRECTS on chrome.

I also suspected it had something to do with this part of the machine configuration: -p 443:8080/tcp:tsl. I tried different combinations just to make sure it wasn’t it but 443:8080/tcp:tsl is the only setup where the app actually loads

5

Well, I also have the following lines, but I can’t honestly tell you why I added it:

6

that didn’t help either…but this change, the force_ssl = true doesn’t do infinite redirects anymore, so that’s something hahaha

7

quick update on this one: I managed to get it working, setting config.force_ssl = true and proxying the app with Cloudflare but I noticed something: the database performance is terrible. I’m using a Postgres machine in fra cloned in gru (where I’m currently sitting). the gru is the replica while fra is the primary. I configured my database.yml as follow:

production:
  primary:
    adapter: postgresql
    username: xxx
    password: xxx
    host: fra.sumiu-pg.internal
    database: sumiu_db
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  primary_replica:
    adapter: postgresql
    username: xxx
    password: xxx
    host: top1.nearest.of.sumiu-pg.internal
    database: sumiu_db
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
    replica: true

I posted the same request on the same app running on Nomad, here is the difference (from logs)

Creating a record

  • Nomad: "duration":846.66,"view":1.75,"db":51.92
  • Machine: "duration":820.44,"view":0.56,"db":589.38

weird that the duration is virtually the same but there is a noticeable slowness when using the Machine version

Updating the record

  • Nomad: "duration":46.59,"view":0.87,"db":1.91
  • Machine: "duration":421.71,"view":0.63,"db":197.33

Not really sure where to start investigate it. Any idea? I want to blame AR’s internal routing between primary/secondary but I doubt it could be this

Should I maybe open a new topic?