[BUG]: Active Storage blob redirects do not obey the path in LAGO_API_URL

[spantaleev]

Describe the bug

I'm serving:

• the frontend (front) at: https://LAGO_HOSTNAME (at the root path)
• the API (api) at https://LAGO_HOSTNAME/api

The api container receives LAGO_API_URL=https://LAGO_HOSTNAME/api, so that it's aware of its own absolute public URL. Likewise, the front container receives an API_URL variable with the same value.

When downloading an invoice from the frontend:

• I see the POST /..../graphql call to generate it.. which responds with a data.fileUrl like https://LAGO_HOSTNAME/api/rails/active_storage/blobs/redirect/STUFF_HERE/DEV-4911-001-003.pdf (note the URL having the correct /api prefix)
• hitting this URL redirects me to https://LAGO_HOSTNAME/rails/active_storage/disk/STUFF_HERE/DEV-4911-001-003.pdf (note the lack of an /api prefix here)
• a 404 page is shown

---

The default docker-compose deployment seems to export the API at its own origin (http://localhost:3000). I suppose your hosted deployments put the API on its own domain (api.SOMETHING). None of these deployments seem to use a subpath for the API, so this kind of usage probably doesn't work perfectly yet.

Based on my limited testing (a few hours of playing around with Lago), hosting the API at an /api path prefix seems to work. It's just this invoice file redirection thing that fails.

The other caveat with exposing the API at /api is to only capture requests with /api/ in the URL (not /api) to avoid capturing the /api-keys.ebbdfaad3d6c7b0d14a7.js frontend file.

[jdenquin]

@spantaleev its recommended to use a domain only URL for API_URL, like myapi.domain or api.mydomain.dom.
It's working well for many usecase but if you use the default configuration of Lago, the ActiveStorage link generation uses only the host of the URI.

Do you have a need to support this kind of configuration in a production environment?

[spantaleev]

I don't really have such a requirement, but I was playing around with Lago and assumed I'd only need a single domain to run the whole thing.

Initially, while building the MASH playbook Ansible role for Lago support (ansible-role-lago), I hoped I'd also be able to run all of Lago under a path prefix (e.g. /lago). We support such a thing for various other services, but hit some problems with the Lago frontend not being configurable to allow this.

So then I gave up on it and thought I'd be able to host it all on a single domain, but it seems like the API needs to be separate. Maybe I missed something in the documentation? It wasn't obvious that I'd need a separate domain for the API.

[jdenquin]

Okay I see!

It's not documented on our side maybe we have to add some words about it or just give the API the ability to support this kind of FRONT_URL.

Do not hesitates to open a PR with this change if you want, we will review it fastly!

[vachmara]

Hi,

I recently encountered a similar issue as I too have been trying to serve both the API and the frontend on the same domain but under different paths.

In my .env I have :

LAGO_API_URL=https://mydomain.com
LAGO_FRONT_URL=https://mydomain.com

I used a reverse proxy on nginx to redirect mydomain.com/api to localhost:3000, same for mydomain.com/rails

In my case, hitting https://LAGO_HOSTNAME/rails/active_storage/blobs/redirect/STUFF_HERE/DEV-4911-001-003.pdf redirect to https://localhost:3000/rails/active_storage/disk/STUFF_HERE/DEV-4911-001-003.pdf

I don't know if this issue is related, I fix my problem by using AWS S3!

[FirePing32]

I solved this by creating a nginx location block, which redirects /rails requests to the backend container.

location /rails {
    proxy_pass http://localhost:3000/rails;
}