[BUG]: Unable to try Lago because of CORS

[qvignaud]

Describe the bug
We are trying to make basic Lago install through Helm working but we're just unable to because of CORS problems.
Whatever we try the front respond with "An error occurred, please reload the application".
The network section of browser (Firefox and Chromium) tells us "http://<ip>:<port>/graphql CORS Failed".

To Reproduce
Steps to reproduce the behavior:

1. Having a kubernetes cluster working.
2. Installing Helm chart helm install --set apiUrl=http://<some-ip>:<some-port> --set frontUrl=http://<some-ip>:<some-port> lago https://github.com/getlago/lago-helm-charts/archive/refs/tags/1.2.1.tar.gz
3. Running kubectl expose deployment lago-front --type NodePort --port 80 and kubectl expose deployment lago-api --type NodePort --port 3000
4. Updating Helm chart with right ports given by NodePort services: helm upgrade --install --set apiUrl=http://<some-ip>:31200 --set frontUrl=http://<some-ip>:30203 lago https://github.com/getlago/lago-helm-charts/archive/refs/tags/1.2.1
5. Connecting to http://<some-ip>:30203
6. Filling Sign Up form
7. Apps respond with "An error occurred, please reload the application" and browser announce CORS Failed for http://<some-ip>:31200.

Expected behavior
Being able to reach the /graphql endpoint.

Screenshots
N/A

Support

• OS: Linux Mint
• Browser: Firefox & Chromium
• Version [e.g. 22]

Additional context
I'm feeling like we're not giving right configuration variables as apiUrl and frontUrl, but we tried with and without http:// prefix, with and without port, and we're encountering continuously this issue at best (else just getting inconsistent URLs).

[Tech-market part]
As it's just a very quick trial between billing metric solutions, and comparatively with the others, we would have expected to be simpler to set up and run Lago, especially with the very short doc given with Helm chart repo. It's a bit sad given it looking to be a powerful solution but hard to try out-of-the-box. If I may suggest you could work on better install/demo documentation because I feel like we're not the only ones to encounter this but still the ones motivated enough to report the problem.
[/Tech-market part]

[Antho331364]

Facing the same problem with graphql endpoint cors issue. I also faced a Letsencrypt configuration issue and couldn't resolve it directly. Faced also at every run of the docker containers the error : Unrecognized command "db:migrate:primary", partially solve by running the migration with the container but the error still appear at every 'docker compose up' command

To solve the Letsencrypt problem, I proxy all requests with an nginx installed on the host in front of Lago but I still face a Cors problem with Graphql from Lago Front.

The first time I heard about Lago was in 2022, when we were looking for alternatives to Stripe but the product and company seemed too young to me at that time. New company, new project, I remembered Lago and told myself that I would try it and give it a chance with 2 more years of development and maturation, but I am a bit disappointed for the moment with the product and of the Lago install process. The product looks great and promising on paper (just clone the repository and run it with Docker), but the reality is a little different. Additionally, the documentation doesn't appear to have been updated in some time.

An advise for you Lago team, Documentation is part of the product and should be treated and maintain with the same strength that the product itself. (words of cto)

You guys just raised $22 million a few months ago, I hope you accelerate development and hire the right people quickly to really propose an out-of-the-box solution.

It would really bother me to have to go through Stripe to manage subscriptions, billings, payments, taxes and everything associated with it because the costs would not be negligible from a business point of view, but their product is solid today.

Your promise and vision is great but unfortunately a bit tainted with an initial installation process that doesn't work, even on a clean machine.

In the meantime, I'll try to fix the Cors issue and provide the workaround in this thread if I find one, but if I can't, I'll resign myself to using Stripe.

[jdenquin]

Hello Guys,

We are working on a better OSS documentation, we know it's not well documented and it will get better very soon.
Nginx/Lets encrypt configuration is also very old and not updated.

@qvignaud did you tried with 80 port?

@Antho331364 We were mainly focused on our product, like you said, Lago is very powerful when it comes to Billing and it provides you a lot of solutions.
We know we have to improve our OSS documentation, also feel free to join our Slack Community and we can help you with your installation process.

CORS issue always comes from bad URL configuration. You need to provide the scheme (http or https).
If you can try the configuration with a 80 port for both services and let me know 🙏

[jdenquin]

btw here is the configuration for CORS https://github.com/getlago/lago-api/blob/main/config/initializers/cors.rb

[Antho331364]

Hello @jdenquin,

Thank you for your answer. I succeed to make it work yesterday evening with the following env variable defined in my .bashrc file:

export LAGO_FRONT_URL=https://mydomainportal.com
export FRONT_PORT=8045
export LAGO_API_URL=https://mydomainportal-api.com
export API_PORT=3500

And below the nginx proxy config in front of lago to handle SSL/TLS connection:

server {
    server_name mydomainportal.com;

    location / {
        proxy_pass http://127.0.0.1:8045; # should match with the lago front port
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mydomainportal.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomainportal.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
server_name mydomainportal-api.com;

location / {
    proxy_pass http://127.0.0.1:3500; # should match with the lago api port
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/mydomainportal-api.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/mydomainportal-api.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

The SSL certificates was generated with the command below executed on the host machine:

sudo apt -y install certbot

sudo apt -y install python3-certbot-nginx

sudo certbot --nginx -d mydomainportal-api.com --non-interactive --agree-tos -m example@mydomain.com

sudo certbot --nginx -d mydomainportal.com --non-interactive --agree-tos -m example@mydomain.com

Hope this will help anyone that faced the SSL and Cors issues.

[jdenquin]

We will update our documentation this month on how to configure Lago with Docker and Traefik/Letsencrypt instead of Nginx

[qvignaud]

Hello @jdenquin ,

I finally got the stuff working but still feel a bit wrong in the way I'm achieving this.
Actually I set up a Nginx Ingress controller in Kubernetes, a tricked a bit the config that way:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: custom-lago-ingress
  annotations:    
    nginx.org/location-snippets: |
      add_header 'Access-Control-Allow-Origin' 'https://*.domain.tld';
      add_header 'Vary' 'Origin';
      add_header 'Access-Control-Allow-Methods' 'GET, PUT, POST, DELETE, OPTIONS';
      add_header 'Access-Control-Allow-Headers' 'DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,apollographql-client-name,apollographql-client-version,x-lago-organization,customer-portal-token';   
spec:
  rules:
    - host: "test-lago.domain.tld"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: lago-front-svc 
                port:
                  number: 80
    - host: "test-lago-api.domain.tld"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: lago-api-svc 
                port:
                  number: 3000

With Helm command:
helm upgrade --install --set apiUrl=https://test-lago-api.domain.tld/ --set frontUrl=https://test-lago.domain.tld/ lago https://github.com/getlago/lago-helm-charts/archive/refs/tags/1.2.1.tar.gz

While it's sufficient for testing lago and making some trial, I'm not comfortable with this configuration (mainly because I'm not totally aware of what the nginx configuration change involves in terms of security).

Also –but it's maybe only me who is wrong– I didn't got a way to make front and API served on the same domain with path selection (nor with different ports), either the server returns 500/503 errors or still facing CORS issue.

[jdenquin]

This looks good, this is also how we do it in our helm chart https://github.com/getlago/lago-helm-charts/blob/main/templates/ingress.yaml

[9M6]

I'm having the same issue,

Access to fetch at 'http://localhost:3000/graphql' from origin 'https://billing.[my-domain].so' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

1. I've set .env domains
2. I've manually changed the endpoints in the docker-compose.yml
3. I tried different sets of endpoints http/https
4. I tried loading .env file both from bash and from docker compose --env-file

My setup is simple digital ocean droplet, with cloudflare A name direct to the droplet. Any idea why is not working?

[doctorpangloss]

This is still an issue in 1.10

[jdenquin]

cc @electrosenpai

[jdenquin]

@9M6 whats the domain you use for LAGO_FRONT_URL ?
It should be https://billing.[my-domain].so, also, using api on a /api and same domain is actually not supported by our CORS configuration.

@doctorpangloss which issue, the headers one?

[jdenquin]

any update on your side guys?

[vaisov-gemba]

I was able to make it work by updating config/initializers/cors.rb.

Steps:

git clone https://github.com/getlago/lago-api.git
vim lago-api/config/initializers/cors.rb

Update with:

# frozen_string_literal: true

# NOTE: Read more: https://github.com/cyu/rack-cors

Rails.application.config.middleware.insert_before(0, Rack::Cors) do
  allow do
    frontend_origin = nil

    if ENV.key?('LAGO_FRONT_URL')
      uri = URI(ENV['LAGO_FRONT_URL'])

      frontend_origin = if uri.port.in?([80, 443])
        uri.host
      else
        [uri.host, uri.port].join(':')
      end

      origins frontend_origin
    elsif ENV.key?('LAGO_DOMAIN')
      origins ENV['LAGO_DOMAIN']
    elsif Rails.env.development?
      origins 'app.lago.dev', 'api', 'lago.ngrok.dev'
    end

    # Add the hardcoded front-end URL for production
    origins 'https://api-lago.mydomain.com' if Rails.env.production?

    resource '*',
      headers: :any,
      methods: %i[get post put patch delete options head],
      credentials: true
  end
end

And then updated docker-compose.yml with:

  api:
    container_name: lago-api
      #image: getlago/api:v1.19.0
    build:
      context: ./lago-api
      dockerfile: Dockerfile

Rebuilt the api and started containers:

docker compose build api
docker compose up -d api

Also had to update nginx config /etc/nginx/conf.d/default.conf inside lago-front container to:

server {
  listen 80;
  listen [::]:80;

  location / {
    add_header Access-Control-Allow-Origin "https://lago.mydomain.com" always;
    add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
    add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
    add_header Access-Control-Allow-Credentials "true" always;

    add_header Content-Security-Policy "frame-ancestors *.force.com *.zive.app *.zive.dev *.localhost *.systeminit.com *.storecommander.com *.storecommander.eu *.dev.storecommander.eu;" always;

    root /usr/share/nginx/html;
    index index.html index.htm;
    try_files $uri $uri/ /index.html =404;
  }

  location /graphql {
    # Handle preflight requests
    if ($request_method = OPTIONS) {
      add_header Access-Control-Allow-Origin "https://lago.mydomain.com" always;
      add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
      add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
      add_header Access-Control-Allow-Credentials "true" always;
      add_header Content-Length 0;
      return 204;
    }

    # Add CORS headers for all other requests
    add_header Access-Control-Allow-Origin "https://lago.mydomain.com" always;
    add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
    add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
    add_header Access-Control-Allow-Credentials "true" always;

    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }

  include /etc/nginx/extra-conf.d/*.conf;
}

[jdenquin]

This do the trick yes, but the LAGO_FRONT_URL should do the same, can you try it with your specific use case, and use only the LAGO_FRONT_URL env var?

# frozen_string_literal: true

# NOTE: Read more: https://github.com/cyu/rack-cors

Rails.application.config.middleware.insert_before(0, Rack::Cors) do
  allow do
    frontend_origin = nil

    if ENV.key?('LAGO_FRONT_URL')
      origins ENV['LAGO_FRONT_URL']
    elsif ENV.key?('LAGO_DOMAIN')
      origins ENV['LAGO_DOMAIN']
    elsif Rails.env.development?
      origins 'app.lago.dev', 'api', 'lago.ngrok.dev'
    end

    resource '*',
      headers: :any,
      methods: %i[get post put patch delete options head],
      credentials: true
  end
end

[HLFH]

@jdenquin Hi, currently using @vaisov-gemba suggestions but replacing config/initializers/cors.rb with your own code. I am also using LAGO_FRONT_URL as suggested.

LAGO_RSA_PRIVATE_KEY="BLABLABLA"
API_PORT=3003
FRONT_PORT=3002
LAGO_API_URL=http://192.168.88.214:3003
API_URL=http://192.168.88.214:3003
LAGO_PDF_URL=http://192.168.88.214:3003
LAGO_FRONT_URL=http://192.168.88.214:3002

And it does work. Thanks!

[jdenquin]

thanks for the feedback @HLFH , we'll do a fix around this asap to avoid having to override this config.
@vaisov-gemba I saw your answer but seems you deleted it, if you can just confirm that it also works on your side!

[vaisov-gemba]

thanks for the feedback @HLFH , we'll do a fix around this asap to avoid having to override this config. @vaisov-gemba I saw your answer but seems you deleted it, if you can just confirm that it also works on your side!

I've deleted because I wasn't sure if it's not working due to Cloudflare Access I have in front or your provided cors.rb. Just tested with your provided file, and it doesn't work. Getting following error in browser console:

Access to fetch at 'https://api-lago.mydomain.com/graphql' from origin 'https://lago.mydomain.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

After restoring to my version of cors.rb it started working.

[jdenquin]

and just to double check, LAGO_FRONT_URL is set as https://lago.mydomain.com right?

[doctorpangloss]

the way cors is configured in lago is incompatible with a recentish browser changed. it has to all be revisited unfortunately.

      proxy_set_header 'Access-Control-Allow-Origin' 'https://frontend.mydomain.com';
      proxy_set_header 'Vary' 'Origin';
      proxy_set_header 'Access-Control-Allow-Methods' 'GET, PUT, POST, DELETE, OPTIONS';
      proxy_set_header 'Access-Control-Allow-Headers' 'DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,apollographql-client-name,apollographql-client-version,x-lago-organization,customer-portal-token';

should be set for both frontend-url and api-url locations when using nginx. this will provide the correct responses for browsers

here is an example ingress using the f5 nginx controller

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    acme.cert-manager.io/http01-edit-in-place: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
    meta.helm.sh/release-name: lago
    meta.helm.sh/release-namespace: default # your namespace here
    nginx.org/location-snippets: |
      proxy_set_header 'Access-Control-Allow-Origin' 'https://frontend.mydomain.com';
      proxy_set_header 'Vary' 'Origin';
      proxy_set_header 'Access-Control-Allow-Methods' 'GET, PUT, POST, DELETE, OPTIONS';
      proxy_set_header 'Access-Control-Allow-Headers' 'DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,apollographql-client-name,apollographql-client-version,x-lago-organization,customer-portal-token';
  name: lago-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
    - host: frontend.mydomain.com
      http:
        paths:
          - backend:
              service:
                name: lago-front-svc
                port:
                  number: 80
            pathType: ImplementationSpecific
    - host: lago-api.mydomain.com
      http:
        paths:
          - backend:
              service:
                name: lago-api-svc
                port:
                  number: 3000
            pathType: ImplementationSpecific
  tls:
    - hosts:
        - frontend.mydomain.com
        - lago-api.mydomain.com
      secretName: lago-ingress-secret

observe this essentially overwrites the cors.rb behavior. it has to be rewritten.

i believe the underlying issue is that the codebase extensively uses custom headers and browsers do not report fine grained errors regarding it. all the custom header information should be encoded into the auth token jwt anyway.

[vaisov-gemba]

and just to double check, LAGO_FRONT_URL is set as https://lago.mydomain.com right?

ah, it's set to lago.mydomain.com. Should I add https:// here?

[jdenquin]

ah, it's set to lago.mydomain.com. Should I add https:// here?

Yes, it should works with https:// !