Unsuscribe link in Email broken for dockerized cachet

[stepps]

I am deploying several instances of cachet (2.3.14) in our docker swarm environment. I have written a python service that queries kibana and opens incidents when needed in cachet. Everything is working as expected.

I have then added configuration to the swarmfile to send emails through mailgun; also this part seems to work flawlessly. I did get the confirmation email, and after confirmation I started receiving emails for each incident event.

Now, revising all components before releasing the solution to prod, I have noticed that the "unsubscribe" and "manage subscription" links are broken.

Instead of the full domain name of the cachet instance, the URL is built using the container name + port:

http://preprod_cachet_cachet_customer:8000/subscribe/manage/a8C7frCxRR5cwQcNwGaODh3NyifmNwiSENg29m8yxy

The only place I am using that notation is in my python service. The service does not have access to a public DNS, so I am pointing it to cachet using the stack + service_name (docker embedded dns service for internal networks). This is also somehow "safer" and faster, because the request is local to the LAN.

My guess is that the unsuscribe email link is generated using the header of the request that generated the notification in the first place. This is not a sane behavior, because it forces api calls to be sent through the internet.

This is a blocker for our usage of cachet in production. Can this behavior be altered though some configuration parameter?

[welcome[bot]]

:wave: Thank you for opening your first issue. I'm just an automated bot that's here to help you get the information you need quicker, so please ignore this message if it doesn't apply to your issue. If you're looking for support, you should try the Slack group by registering your email address at https://cachethq-slack.herokuapp.com. Alternatively, email [email protected] for our Professional support service (please note, this a paid service. If you're issue is with documentation, you can suggest edits by clicking the Suggest Edits link on any page, or open an issue at https://github.com/CachetHQ/Docs

[jbrooksuk]

I have written a python service that queries kibana and opens incidents when needed in cachet.

This sounds cool. Any plans to open source it?

What version of Cachet are you using? If you're using 2.3 then have a look at https://github.com/CachetHQ/Docker/commit/02025a70ff267972054e28c2818cde446bb98e48. It may also be useful to open this issue in CachetHQ/Docker.

[stepps]

I am using cachet 2.3. I will look into the trusted proxy setting. Docker-swarm-wise I got pretty far, but I could not solve the issue. What I did is adding an alias for cachet in the other monitoring service, so the issue is opened with the http header corresponding with the cachet domain. What doesn't work is that port 8000 is added to the URL, but the balancer I have in front of cachet listens 80 and 443 only. I The TRUSTED_PROXIES env var did not change the behaviour at all. I have also set APP_URL, which I wasn't setting before, but that did not change the behaviour either.

I am probably gonna put a traefik proxy in front of the cachets cluster.

Regarding the python service, it is very basic: a procedural script that queries a specific ELK index for events and acts accordingly. It runs every minute with a cron. I have written it for the company I work for during office time, so it is not my decision to open source it or not.

[GrahamCampbell]

Did you set the app url on setup?