mirror of
https://github.com/healthchecks/healthchecks.git
synced 2026-04-25 23:15:49 +03:00
[GH-ISSUE #382] URLs in notification emails and Badge URLs are broken when using a subpath #289
Labels
No labels
bug
bug
bug
feature
good-first-issue
new integration
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/healthchecks#289
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @s1shed on GitHub (Jun 13, 2020).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/382
I'm running healthchecks (revision
beff11ceff) with uwsgi and nginx using/hc/as a subpath.The related part of
local_settings.pyThe related uwsgi config looks like:
As far as I can tell, everything works fine except that when going to https://domain.tld/hc/projects/{UUID}/badges/ the URLs for the badges have the subpath specified twice, e.g. https://doman.tld/hc/hc/badge/{UUID}/{RANDSTRING}.svg. If I remove the duplicated
/hcfrom the path the image loads fine.Edit: I also see that the links in notification emails have the subpath doubled in the URL, e.g. https://domain.tld/hc/hc/integrations/{UUID]/unsub/{RANDSTRING}
@s1shed commented on GitHub (Jun 13, 2020):
I've also found that without the subpath in the SITE_ROOT variable:
Everything else seems to work, including that the URLs for the badges are correct
@cuu508 commented on GitHub (Jun 19, 2020):
Thank you for the report!
To be honest, I'm not very familiar with hosting Django apps in subpaths. For reference, my current understanding is that SITE_ROOT should only contain scheme, domain and port, and no path. Django will get the path either from the SCRIPT_NAME env variable, or from the FORCE_SCRIPT_NAME setting. IOW, this should work:
And this probably shouldn't:
I assume you are able to log in, but after logging in you don't get redirected to the project or the check you were trying to access, correct?
Not sure, but this could be a bug in
django.urls.resolve, filed a ticket and will see what comes out of it: https://code.djangoproject.com/ticket/31724Thanks, that's something I'll need to fix.