#21
|
||||
|
||||
das ganze kann man vorab schon mal unter beta.jdownloader betrachten. Finde ich Klasse.
Die http://img254.imageshack.us/img254/8945/jdw.png Übersicht finde ich auch sehr gut! Vor allem wenn man in Zukunft mit Userscripts werkeln kann.
__________________
sorry about my gramma (dyslexia).
——————————————————————————————————— SuFu/Google: Inoffizielle JDownloader Plugins, Erweiterungen, Addons & Tools |
#22
|
|||
|
|||
Also auf my.jdownloader.org/ gibts diese Übersicht nicht und die Weboberfläche dort sieht auch anders aus.
|
#23
|
|||
|
|||
Wo aktiviere ich das Webinterface? Finde nirgends einen Eintrag.
Kann man weiterhin mit Smartphones und diversen Remote APKs den JDownloader fernbedienen?, Auch hier finde ich keinen Eintrag wo man die Portnummer sieht oder ändern kann. Weiss jemand Rat? |
#24
|
|||
|
|||
|
#25
|
|||
|
|||
Seems to be a bit buggy; i entered my e-mail, received the key, entered it in < 1 min and got a "key expired" message - three times in a row.
|
#26
|
|||
|
|||
I just tried to register a new account and it worked fine.
Did your registration work on the fourth time or did you give up after three attempts? |
#27
|
|||
|
|||
Now the login is working.
However, in JD2 settings I cannot see the my.jdownloader.org-Plugin. Would I have to install it manually or activate it somewhere? Last edited by caid602; 17.07.2013 at 09:01. |
#28
|
||||
|
||||
oh Rly?
Check the Settings Sidebar. There is a brand new My JDownloader entry
__________________
|
#29
|
|||
|
|||
Quote:
Ich finde es schon merkwürdig, dass es einige Entwickler gab, die sich für lau an AppWork verkauft haben und ihre Rechte am eigenen Code abgetreten haben. Und wie es sich anhört, würden die Entwickler ein echtes remote-Webinterface nicht mal mehr ins Programm aufnehmen. Last edited by pcworld; 17.07.2013 at 20:09. |
#30
|
|||
|
|||
Quote:
Quote:
Aber ich versuche jetzt erst mal weiterhin optimistisch zu bleiben und hoffe, dass die Aussage von coalado weiterhin Bestand hat und es wenigsten so ein "Direct-Mode" API geben wird. API muss ja jetzt nicht unbedingt "komplettes Webinterface" bedeuten - vermutlich sogar eher nicht - aber dann bestünde wenigstens Hoffnung, dass man dann zumindest ein unabhängiges Webinterface oder 'ne App stricken könnte. |
#31
|
|||
|
|||
Ich seh da auch keinen Sinn drin, da bleib ich eher bei Pyload.
Das Dashboard läd übrigens nicht, hab ich grad mal probiert. |
#32
|
||||
|
||||
Sooo... also gehen wir mal konstruktiv ran.
Helft mir doch mal etwas und erklärt welche Punkte genau stören. Über das Wort "proprietär" könnte man vermutlich streiten. Ich habe das bisher immer als "geschlossen/unbekannt" verstanden. Die Funktionsweise des MyJDowloader Servers, und vor allem der Verschlüsselung ist jetzt alles andere als unbekannt. Sicher. Er ist nicht quelloffen, die Funktionsweise lässt sich aber ziemlich genau aus der API lesen. Viele sprechen eine direkte Verbindung an. Das wirft gleich die erste Frage auf. So ein Webinterface besteht aus einem statischen Teil (Der liegt auf my.jdownloader.org) und dem "dynamischen Teil". Das sind die API Calls, die den statischen Teil quasi mit Leben füllen. Diese Trennung macht Sinn! Die selbe API füttert nicht nur das Webinterface mit Daten, sondern auch Mobile Apps. Abgesehen davon, macht wes wenig Sinn solche Daten über eine langsamme Verbindung vom JD zu laden. Früher gab es so eine API auch. Da hieß sie "RemoteControl Addon", und war bei weitem nicht so umfangreich, allerdings direkt erreichbar. Ich habe also schonmal 2 "Module": 1. Statisches Webinterface auf my.jdownloader.org 2. API Zugriff auf JDownloader über api.jdownloader.org 1. Kann eigerntlich überall liegen. Das könnte man sich genauso runterladen und lokal ausführen. Das könnte auch JDownloader selbst bereitstellen. Jeder kann sich das Zeug auch auf einben eigenen Server legen, und dann z.B. über **External links are only visible to Support Staff**www.meineeigenedomain192.de zugreifen. Das geht eigentlich jetzt schon. Da das webinterface aber weit weg von fertig ist, würde ich das nicht empfehlen. Da macht es schon eher Sinn was eigenes zu bauen. Falls es jemand wichtig ist, dass er nicht auf My.jdownloader.org geht, sondern auf meineiup.dyndns.org, um sich den Statischen Teil auch von JDownloader ausliefern zu lassen, könnte man das wieder über eine Extension lösen. Wie gesagt.. FALLS das jemandem wichtig ist. Sagt ihr es mir. 2. Das ist das eigentliche Herzstück, und ich vermute, dass damit die meisten hier ein Problem haben. Jeder Call geht verschlüsselt über den api.jdownloader.org Server. Der Verschlüsselung kann man trauen. Falls jemand Einwände hat, soll er das bitte sagen. Wir sind um jede aufgedeckte Lücke dankbar. Ich will aber vorwegschicken, dass my.jdownloader.org demnächst auf https umgestellt werden wird. Ohne https, ist das meiner meinung nach momentan die einzige "Schwachstelle" Vielen geht es aber vermutlich auch um den Speed. Gerade im LAN ist so eine direkte Verbindung natürlich schneller. Wir wollen auch irgendwann über das Webinterface den Zugriff auf die geladenen Daten erlauben. Sowas kann nicht über unsere Server laufen. Da würden uns die Traffickosten erdrücken. Ein Vorschlag wäre, dass über die gesicherte api.jdownloader.org eine direkte Verbindung zu einem Device (an ein my.jdownloader.org Konto können ja mehrere Devices (JD) verwaltet werden) aufgebaut werden kann. Wobei auch gleich ein Zufalls Schlüssel (vom Client generiert oder vom Nutzer eingetragen) ausgetauscht wird. api.jdownloader.org/directRequest?key=1736522367462&deviceid=blablala Der entsprechende JD (ID blablala) schaltet die API für die anfragende IP frei, und gibt die eigene IP:port zurück. Ab jetzt kann mit dem JD direkt kommuniziert werden. Falls die JD IP sicht oft ändert (Reconnects) muss noch irgendeine Art von dyndns Service dazwischen. Vieleicht bauen wir sowas selbst. Oder man nutzt halt einen bestehenden. Gibt ja genug. Jeglicher Traffic wird dabei mit dem Key verschlüsselt. Um das entsprechende port forwarding muss sich der Nutzer entweder selber kümmern, oder wir lassen das JD über UPNP (falls möglich) selbst machen. Später kann man eventl ein Holepunching System nutzen. Auf jeden Fall wäre die JD Kommunikation dann direkt, und verschlüsselt, und ziemlich sicher. Dennoch wäre ein MyJDownloader Account nötig um die direkte Verbindung her zu stellen. Was haltet ihr von der Idee?
__________________
|
#33
|
|||
|
|||
Für pyload brauche ich keinen Account, nur die auf dem NAS installierte Software. Ich wähl mich per VPN auf den Router ein, hinter dem das NAS liegt. Oder ich wähl mich ohne VPN per Browser über einen nur mir bekannten Port auf dem NAS direkt auf dem Webinterface ein.
Warum sollte ich es irgendwie umständlicher haben wollen? |
#34
|
||||
|
||||
Umständlicher? Also das ist jetzt mal ein wirkliches Argument.
VPN, Dyndns, Router konfigurieren, Zusatzsoftware auf dem Remote Gerät (VPN),.... das sind eigentlich alles Dinge die wir dem Nutzer gerne ersparen würden. Also man kann über MyJDownloader ja viel sagen. Aber "umständlicher" gehört echt nicht dazu.
__________________
|
#35
|
|||
|
|||
Und was ist mit der 2. Variante ohne VPN (das bei meiner Uralt-Fritzbox übrigens kinderleicht einzurichten ist)?
Warum soll ich über euren Server gehen, wenn es ohne problemlos möglich ist? Hab keine Lust drauf, das irgendwer mitliest, was ich so lade. |
#36
|
|||
|
|||
Quote:
Ich habe eine feste IP. Ich habe einen Router der Port Forwarding unterstützt. Was mir fehlt ist ein Webinterface was lokal auf dem JDownloader läuft und SSL mit User/Passwort Authentifizierung unterstützt. Mehr brauche ich nicht. (Praktisch wie unter JDv1 und der alten Remote API, nur in besser und sicherer, aber trotzdem in unserer Kontrolle!) Wenn ich dann auch noch eine echte Remote GUI bekomme also mit einem JDownloader auf einen anderen zugreifen kann, aber die Lokales des Ziels verwendet werden mache ich eine Flashe Champus auf! Gruß David Last edited by Davidh2k; 21.07.2013 at 16:58. |
#37
|
|||
|
|||
Quote:
pcworld hatte ja zuvor die Vermutung (Feststellung?) geäußert, dass "die Entwickler ein echtes remote-Webinterface nicht mal mehr ins Programm aufnehmen" würden. Ich will dir jetzt nicht zu nahe treten, aber deine Ausführen klingen für mich jetzt nicht unbedingt wie ein klares und eindeutiges Dementi. Ganz im Gegenteil. Aber lasst uns jetzt bitte nicht über das Pro und Contra der unterschiedlichen Lösungen diskutieren. Wie beinahe immer im Leben gibt es bei allem Vor- und auch Nachteile. Bei my.jdownloader.org ist das nicht anders. Man kann aber festhalten, dass es Benutzer gibt, die die Lösung über my.jdownloader.org nicht verwenden wollen und die entscheidende Frage ist jetzt ganz einfach, wie stehen die aktuellen Entwickler zu einer Alternative, mit der man den JD "direkt" steuern kann - sei es jetzt ein zusätzliches Webinterface oder eine separate Anwendung/App oder whatever. Selbstverständlich kann hier niemand, der nicht selber an JD mitarbeitet, irgendwelche Forderungen stellen, und es ist klar, dass ein zusätzliches Interface auch zusätzliche Arbeit bedeuten würde, aber es wäre wenigstens gut zu wissen, ob in Zukunft weiterhin die theoretische Möglichkeit dafür bestehen würde oder ob beispielsweise einem eventuell extern entwickelten "RemoteControl Addon" im Extremfall sogar Steine in den Weg gelegt würden. |
#38
|
||||
|
||||
Für mich ist MyJDownloader ein echtes RemoteInterface.
Ich bin für ziemlich alles zu haben - auch direkte Kommunikation - aber zumindest für die Authentifizierung wird ein MyJDownloader Account nötig sein. Es gibt eine API, diese ist über ein MyJDownloader Konto verschlüsselt. Nach dem "Login" kann ich mir eine direkte Verbindung (Ohne den MyJDownloader Server dazwischen) gut vorstellen. Aber zumindest für die Authentifizierung wird ein MYJD Konto benötigt werden. Und ja.... wir werden Erweiterungen und ko, die das umgehen wollen sicherlich nicht freudig empfangen.
__________________
|
#39
|
||||
|
||||
Ein echtes RemoteInterface benötigt nicht eine weitere Stelle dazwischen. Viele werden die aktuelle Art begrüssen aber viele auch wieder nicht, wozu ich ebenfalls gehöre. Ich hätte gerne die vollständige Kontrolle, ganz gleich wie stark es verschlüsselt sein mag.
Quote:
Direkte Kommunikation wäre ein Anfang. Als Login sollte man Openid überlegen.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#40
|
||||
|
||||
Ich denke nicht dass wir den Login auf OpenID ändern werden.
Ein Grund für die Kontobindung ist, dass es im JDownloader demnächst auch bezahlte Premiumfunktionen geben wird. Solche Premiumfunktionen wird es auch im Webinterface oder anderen Remote Apps geben. Dazu werden zum Beispiel die Art oder die Häufigkeit bestimmter API Funktionen limitiert sein. Das geht ohne Kontrolle nicht. Die Antwort wird den meisten vermutlich nicht sonderlich gefallen. Jetzt könne man natürlich die API Bereiche die ohnehin komplett unlimitiert sind(momentan sind das alle) ohne MyJDownloader Bindung zugänglich machen. Und dann? Wer arbeitet dann damit? Vermutlich haben wir damit ziemlich viel Arbeit, für verhältnismäßig wenig Nutzer.
__________________
|
Thread Tools | |
Display Modes | |
|
|