selfhosted webinterface for jdownloader
remove dependency on the centralized tunneling service my.jdownloader.org
alternatives to my.jdownloader.org
my.jdownloader.org is just a tunneling service, needed for port-forwarding through closed firewalls, to expose a listening port to the internet
the tunneling service also serves as a cors proxy, otherwise the webapp could not connect to jdownloader at http://localhost:3128/, so even with the "direct connection" mode, the connection is still routed through my.jdownloader.org
a tunneling service is not needed when accessing jdownloader behind a firewall with enabled port-forwarding for jdownloader's port 3128
to check if a port is reachable from the internet, you can use
nmap -p 3128 $your_public_ip_addressnmap -p 3128 your-public-domain-name.duckdns.orgjdownloader has a hidden Deprecated API feature
dst="$HOME/.config/jdownloader"
cfg="$dst"/cfg/org.jdownloader.api.RemoteAPIConfig.json
if [ "$(cat "$cfg" | jq -r .deprecatedapienabled)" = "false" ]; then
cat "$cfg" | jq -c '. * { "deprecatedapienabled": true }' | sponge "$cfg"
fiMy.JDownloader API Documentation Pro Tip: It's possible to access the JDownloader API directly (Bypass our server) by enabling the so called 'Deprecated API' in the Advanced Options.
when the Deprecated API is enabled,
jdownloader will listen on port 3128
see localhost:3128/help for the API docs
now with jdownloader running, you can start the webinterface with
nix-shell
./myjdownloader.pyby default, the webinterface is listening on http://localhost:3129/
the initial version was created with webapps-scraper from my.jdownloader.org
the minified javascript sources were unpacked with webcrack
webcrack failed to unpack javascript files generated by GWT so i had to unpack these files with unpack-cache-js-files.sh and unpack-deferredjs-files.sh
since jdownloader is ruled by idiots (they still use SVN, Core.jar is still closed-source, ...) i expect that this repo will be censored on github.com so im creating consorship-resistant mirrors in advance