Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] healthcheck fails due to redirect response (302) when using https #843

Closed
5 tasks done
amcusack opened this issue Aug 13, 2022 · 3 comments
Closed
5 tasks done
Assignees
Labels
🐛 Bug [ISSUE] Ticket describing something that isn't working 🕸️ Duplicate [ISSUE] This issue or pull request already exists

Comments

@amcusack
Copy link

Environment

Self-Hosted (Docker)

System

Debian GNU/Linux 11 (bullseye) / Docker version 20.10.5+dfsg1, build 55c4c88

Version

Dashy version 2.1.1

Describe the problem

I am running Dashy in a docker container on debian.

I specify my own ssl certificate as per instructions at https://github.com/Lissy93/dashy/blob/master/docs/management.md#passing-a-self-signed-certificate-to-dashy

dashy runs fine with https on port 443 , has correct certificate, no errors in log, able to configure & run with no problems.

the only issue is the healthcheck..

its fails due to a redirect (302) message returned - (redirection from http to https i assume)

the command used to test healthceck is:

docker exec -it dashy yarn health-check

the result is :

yarn run v1.22.15
$ node services/healthcheck
[Sat Aug 13 2022 12:10:24 GMT+0930 (GMT+09:30)] Running health check...
Status: 302
Request took 0.028 seconds
---
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Is there someway to get the healthcheck to test against https (443) instead of http (80)

my workaroud is to specify

healthcheck: 
  disable: true

in the docker-compose.yml but it would be nice to have healthcheck active.

Thanks.

Additional info

No response

Please tick the boxes

@amcusack amcusack added the 🐛 Bug [ISSUE] Ticket describing something that isn't working label Aug 13, 2022
@liss-bot
Copy link
Collaborator

If you're enjoying Dashy, consider dropping us a ⭐
🤖 I'm a bot, and this message was automated

@Lissy93
Copy link
Owner

Lissy93 commented Aug 14, 2022

Closing as dup of #840 and #768

@Lissy93 Lissy93 closed this as completed Aug 14, 2022
@Lissy93 Lissy93 added the 🕸️ Duplicate [ISSUE] This issue or pull request already exists label Aug 14, 2022
@nwh3365
Copy link

nwh3365 commented Dec 10, 2023

I have been having the same issue. I think the issue is with the isSsl test at the beginning of healthcheck.js. It is determining if SSL is applicable strictly based on the SSL-related environment variables (SSL_PRIV_KEY_PATH and SSL_PUB_KEY_PATH) that are mentioned in the docs amcusack linked:

Passing a Self-Signed Certificate to Dashy
Once you've generated your SSL cert, you'll need to pass it to Dashy. This can be done by specifying the paths to your public and private keys using the SSL_PRIV_KEY_PATH and SSL_PUB_KEY_PATH environmental variables. Or if you're using Docker, then just pass public + private SSL keys in under /etc/ssl/certs/dashy-pub.pem and /etc/ssl/certs/dashy-priv.key respectively

The docs indicate that with Docker you just need to pass the key files to the container (without specifying the environment variables), and indeed Dashy will run in SSL mode by doing so. However, because healthcheck.js is only using the environment variables to determine the SSL status, if you don't set them it assumes non-SSL and ultimately fails because it gets a "302 Found" instead of a "200 OK".

Ideally, the isSsl check should probably include whatever mechanism Dashy is using to put itself in SSL mode based on the presence of the key files in the container, however you can work around this issue simply by specifying the environment variables with docker run / docker compose:

--env SSL_PUB_KEY_PATH="/etc/ssl/certs/dashy-pub.pem"
--env SSL_PRIV_KEY_PATH="/etc/ssl/certs/dashy-priv.key" \

By specifying the environment variables (in addition to passing the key files), the isSsl check determines the correct SSL status and the rest of the healthcheck proceeds as it should.

This issue has been closed as a duplicate of #768 and #840, however it isn't resolved by those issues. I'm going to create a new issue for it with the additional details, but wanted to post the workaround here for those that may find this issue (#843).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 Bug [ISSUE] Ticket describing something that isn't working 🕸️ Duplicate [ISSUE] This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

4 participants