search

cachethq / Docker

A Dockerized version of Cachet.
https://cachethq.io
BSD 3-Clause "New" or "Revised" License
416 stars 280 forks source link

Unsuscribe link in Email broken for dockerized cachet #329

Open stepps opened 6 years ago

stepps commented 6 years ago

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] commented 6 years ago

: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 support@alt-three.com 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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

Did you set the app url on setup?