[GH-ISSUE #382] URLs in notification emails and Badge URLs are broken when using a subpath #289

Closed
opened 2026-02-25 23:41:55 +03:00 by kerem · 2 comments
Owner

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.py

SITE_ROOT = "https://domain.tld/hc"
PING_ENDPOINT = "https://domain.tld/hc/ping/"
STATIC_URL = '/hc/static/'
FORCE_SCRIPT_NAME = '/hc'

The related uwsgi config looks like:

mount = /hc=hc/wsgi.py
manage-script-name = true

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 /hc from 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}

Originally created by @s1shed on GitHub (Jun 13, 2020). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/382 I'm running healthchecks (revision beff11ceff90735abcb2a227f76a0bee07247a3f) with uwsgi and nginx using `/hc/` as a subpath. The related part of `local_settings.py` ``` SITE_ROOT = "https://domain.tld/hc" PING_ENDPOINT = "https://domain.tld/hc/ping/" STATIC_URL = '/hc/static/' FORCE_SCRIPT_NAME = '/hc' ``` The related uwsgi config looks like: ``` mount = /hc=hc/wsgi.py manage-script-name = true ``` 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 `/hc` from 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}
kerem 2026-02-25 23:41:55 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@s1shed commented on GitHub (Jun 13, 2020):

I've also found that without the subpath in the SITE_ROOT variable:

  • redirecting to the login page, such as when clicking link in a notification email, doesn't use the subpath
  • all of the API URLs at https://domain.tld/hc/docs/api/ lack the subpath

Everything else seems to work, including that the URLs for the badges are correct

<!-- gh-comment-id:643646432 --> @s1shed commented on GitHub (Jun 13, 2020): I've also found that without the subpath in the SITE_ROOT variable: * redirecting to the login page, such as when clicking link in a notification email, doesn't use the subpath * all of the API URLs at https://domain.tld/hc/docs/api/ lack the subpath Everything else seems to work, including that the URLs for the badges are correct
Author
Owner

@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:

FORCE_SCRIPT_NAME = "/hc"
SITE_ROOT = "https://domain.tld"

And this probably shouldn't:

SITE_ROOT = "https://domain.tld/hc"

redirecting to the login page, such as when clicking link in a notification email, doesn't use the subpath

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/31724

all of the API URLs at https://domain.tld/hc/docs/api/ lack the subpath

Thanks, that's something I'll need to fix.

<!-- gh-comment-id:646633651 --> @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: FORCE_SCRIPT_NAME = "/hc" SITE_ROOT = "https://domain.tld" And this probably shouldn't: SITE_ROOT = "https://domain.tld/hc" > redirecting to the login page, such as when clicking link in a notification email, doesn't use the subpath 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/31724 > all of the API URLs at https://domain.tld/hc/docs/api/ lack the subpath Thanks, that's something I'll need to fix.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/healthchecks#289
No description provided.