getlago / lago

Open Source Metering and Usage Based Billing API ⭐️ Consumption tracking, Subscription management, Pricing iterations, Payment orchestration & Revenue analytics
https://www.getlago.com
GNU Affero General Public License v3.0
6.75k stars 290 forks source link

[BUG]: Unable to try Lago because of CORS #368

Open qvignaud opened 1 month ago

qvignaud commented 1 month ago

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

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Antho331364 commented 1 month ago

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 commented 1 month ago

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

qvignaud commented 1 month ago

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 commented 1 month ago

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