dutchcoders/transfer.sh
1
0
Fork 0
mirror of https://github.com/dutchcoders/transfer.sh.git synced 2026-02-03 14:13:26 +00:00
Code Issues 48 Actions Packages Projects Releases Wiki Activity

Endless redirects using SSL/TLS with docker-image #141

New Issue
Closed
opened 2026-01-19 18:29:09 +00:00 by michael · 8 comments
michael commented 2026-01-19 18:29:09 +00:00
Owner
Copy Link

Originally created by @yelodevopsi on GitHub.

Hi!

I'm trying to run the dutchcoders/transfer.sh:latest docker image, utilizing the TLS/SSL feature.

The closest I've come, using the host-os's cert and priv-keys:

docker run --publish 8080:8080 --publish 443:443 \
	--volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \
	--provider local \
	--basedir /tmp/ \
	--force-https true \
	--tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \
	--tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \
	--tls-listener :443

But I'm faced with endless 308 redirects when doing this.
Is this because the Dockerfile only exposes 8080 I presume?

Apache proxy workaround
As a temporary workaround I'm able to make the frondend https using a Apache2 proxy setup, but download-links and all the URL's are still set to http://, thus most browser are blocking any downloads I'm sharing directly.

<VirtualHost *:443>

    ProxyPreserveHost On
    ProxyRequests Off
    ServerName my.domain.com
    ServerAlias my.domain.com
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/


    ErrorLog ${APACHE_LOG_DIR}/gule.cloud-error.log
    CustomLog ${APACHE_LOG_DIR}/gule.cloud-access.log combined

SSLCertificateFile /etc/letsencrypt/live/my.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Suggestions

  • Would it be possible to add a hostname/domain-flag (--domain https:://my.domain.com) or other prefix to the parameters?
  • I've also managed to hack a half-assed workaround using --proxy-path https://my.domain.com, but this screws up all the base-url's in the examples and the frontend at large.
Originally created by @yelodevopsi on GitHub. Hi! I'm trying to run the dutchcoders/transfer.sh:latest docker image, utilizing the TLS/SSL feature. The closest I've come, using the host-os's cert and priv-keys: ```bash docker run --publish 8080:8080 --publish 443:443 \ --volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \ --provider local \ --basedir /tmp/ \ --force-https true \ --tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \ --tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \ --tls-listener :443 ``` But I'm faced with endless 308 redirects when doing this. Is this because the Dockerfile only exposes 8080 I presume? **Apache proxy workaround** As a temporary workaround I'm able to make the frondend https using a Apache2 proxy setup, but download-links and all the URL's are still set to http://, thus most browser are blocking any downloads I'm sharing directly. ```apache2 <VirtualHost *:443> ProxyPreserveHost On ProxyRequests Off ServerName my.domain.com ServerAlias my.domain.com ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/ ErrorLog ${APACHE_LOG_DIR}/gule.cloud-error.log CustomLog ${APACHE_LOG_DIR}/gule.cloud-access.log combined SSLCertificateFile /etc/letsencrypt/live/my.domain.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.com/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf </VirtualHost> ``` **Suggestions** * Would it be possible to add a hostname/domain-flag (--domain https:://my.domain.com) or other prefix to the parameters? * I've also managed to hack a half-assed workaround using --proxy-path https://my.domain.com, but this screws up all the base-url's in the examples and the frontend at large.
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@paolafrancesca commented on GitHub:

@rompeldunk
there was actually a bug in the redirect handler, fixed on #441

@paolafrancesca commented on GitHub: @rompeldunk there was actually a bug in the redirect handler, fixed on #441
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@yelodevopsi commented on GitHub:

Seem that the error still persist after I purged and pulled :latest tag.

Could you confirm that you're able to run the SSL-based transfer.sh docker image?
I'm still testing with the command above.

@yelodevopsi commented on GitHub: Seem that the error still persist after I purged and pulled :latest tag. Could you confirm that you're able to run the SSL-based transfer.sh docker image? I'm still testing with the command above.
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@yelodevopsi commented on GitHub:

Thanks for the quick reply!

Yes, I corrected that error previously and tested without true too - Still the redirect problem persists.
The command below is tested without Apache2 (proxy) running, but gives the exact same output as if it was active (Virtucal config in my previous comment)

I've replaced my real domain with the my.domain.com and IP with 123.123.123.123 in the terminal code below:

root@lnx:~# docker run --publish 8080:8080 --publish 443:443 \
> --volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \
> --provider local \
> --basedir /tmp/ \
> --force-https \
> --tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \
> --tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \
> --tls-listener :443
[transfer.sh]2021/12/07 08:18:09 Transfer.sh server started.
using temp folder: /tmp/
using storage provider: local
[transfer.sh]2021/12/07 08:18:09 listening on port: :8080
[transfer.sh]2021/12/07 08:18:09 listening on port: :443
[transfer.sh]2021/12/07 08:18:09 ---------------------------
[transfer.sh]2021/12/07 08:18:19 123.123.123.123:50940 - - [2021-12-07T08:18:19Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
[transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308  "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

Do you know or have any setups/examples with docker containers running transfer.sh with SSL?
I suspect there might be an issue with either any of the flags/a bug/ or that the dutchcoders/transfer.sh:latest image might not be applicable for using SSL?

Also: I tested with adding EXPOSE 443 to the Dockerfile and build it locally and test, but the redirect problem is the same.

@yelodevopsi commented on GitHub: Thanks for the quick reply! Yes, I corrected that error previously and tested without `true` too - Still the redirect problem persists. The command below is tested without Apache2 (proxy) running, but gives the exact same output as if it was active (Virtucal config in my previous comment) I've replaced my real domain with the my.domain.com and IP with 123.123.123.123 in the terminal code below: ``` root@lnx:~# docker run --publish 8080:8080 --publish 443:443 \ > --volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \ > --provider local \ > --basedir /tmp/ \ > --force-https \ > --tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \ > --tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \ > --tls-listener :443 [transfer.sh]2021/12/07 08:18:09 Transfer.sh server started. using temp folder: /tmp/ using storage provider: local [transfer.sh]2021/12/07 08:18:09 listening on port: :8080 [transfer.sh]2021/12/07 08:18:09 listening on port: :443 [transfer.sh]2021/12/07 08:18:09 --------------------------- [transfer.sh]2021/12/07 08:18:19 123.123.123.123:50940 - - [2021-12-07T08:18:19Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36" [transfer.sh]2021/12/07 08:18:20 123.123.123.123:50940 - - [2021-12-07T08:18:20Z] "GET / HTTP/2.0" 308 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 ``` Do you know or have any setups/examples with docker containers running transfer.sh with SSL? I suspect there might be an issue with either any of the flags/a bug/ or that the dutchcoders/transfer.sh:latest image might not be applicable for using SSL? **Also:** I tested with adding `EXPOSE 443` to the Dockerfile and build it locally and test, but the redirect problem is the same.
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@paolafrancesca commented on GitHub:

@rompeldunk
--force-https is a boolean flag, you don't need to pass true as a value, setting it is enough
passing true seems to break the parsing of the rest of the command arguments and indeed your tls listener is never started.
You can try the following:

docker run --publish 8080:8080 --publish 443:443 \
	--volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \
	--provider local \
	--basedir /tmp/ \
	--force-https \
	--tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \
	--tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \
	--tls-listener :443

It should work

@paolafrancesca commented on GitHub: @rompeldunk `--force-https` is a boolean flag, you don't need to pass `true` as a value, setting it is enough passing `true` seems to break the parsing of the rest of the command arguments and indeed your tls listener is never started. You can try the following: ``` docker run --publish 8080:8080 --publish 443:443 \ --volume /etc/letsencrypt:/etc/letsencrypt dutchcoders/transfer.sh:latest \ --provider local \ --basedir /tmp/ \ --force-https \ --tls-cert-file /etc/letsencrypt/live/my.domain.com/fullchain.pem \ --tls-private-key /etc/letsencrypt/live/my.domain.com/privkey.pem \ --tls-listener :443 ``` It should work
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@paolafrancesca commented on GitHub:

https://hub.docker.com/r/dutchcoders/transfer.sh/tags

it seems the docker image is not updated yet

@paolafrancesca commented on GitHub: https://hub.docker.com/r/dutchcoders/transfer.sh/tags it seems the docker image is not updated yet
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@paolafrancesca commented on GitHub:

the workflow was still running on master, fixed now, in a few minutes we should have the new docker image

@paolafrancesca commented on GitHub: the workflow was still running on `master`, fixed now, in a few minutes we should have the new docker image
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@yelodevopsi commented on GitHub:

Yes. Just confirmed it the latest docker pull! Thanks alot! 👍

@yelodevopsi commented on GitHub: Yes. Just confirmed it the latest docker pull! Thanks alot! 👍
michael commented 2026-01-19 18:29:09 +00:00
Author
Owner
Copy Link

@paolafrancesca commented on GitHub:

is it working now @rompeldunk ?

@paolafrancesca commented on GitHub: is it working now @rompeldunk ?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
docker
enhancement
hacktoberfest
help wanted
invalid
question
storage provider
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#141
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?