mirror of
https://github.com/snibox/snibox.git
synced 2026-04-25 15:56:04 +03:00
[GH-ISSUE #84] Snibox redirects without port on SSL? #59
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/snibox#59
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 @nitobuendia on GitHub (May 21, 2022).
Original GitHub issue: https://github.com/snibox/snibox/issues/84
Context and Issue Explanation
I have a copy of Snibox running on docker. Snibox runs on port XX80 (e.g. 6080) on HTTP, which is mapped to snibox port 80. I have a nginx proxy on top of it to enable HTTPS on a port other than 443 or 80 (e.g. 95). On top of this, I have my domain pointing to the right IPs for Snibox and/or NGINX as needed.
This does not happen with the other docker apps I have under the same NGINX configuration, so I don't think it's related to the NGINX configuration, but I could be wrong.
Expected Behaviour
Accessing https://snibox.mydomain.com:95 should redirect to https://snibox.mydomain.com:95/login
Actual Behaviour
Accessing https://snibox.mydomain.com:95 redirects to https://snibox.mydomain.com/login and fails to load.
Questions
Is there a way to modify this redirect to include the port?
Snibox Docker Configuration
This is my docker-compose.yaml for Snibox:
NGINX Site Configuration
This is my NGINX configuration:
@nitobuendia commented on GitHub (May 21, 2022):
I am not very savvy with Ruby, but I have a hypothesis of what may be happening.
I would assume the culprit might be this line here where the redirects happens for logged out users.
The issue seems similar than here. Since Snibox within the docker container is listening on port 80, when the redirect happens, it sends the user to port 80. Instead, we should be checking the port that has been called and add it to the redirect so it gets sent to the right port from where it came.
@nitobuendia commented on GitHub (May 23, 2022):
I think I fixed the issue replacing
proxy_set_header Host $host;with
proxy_set_header Host $host:$server_port;