RemoteAPI.deprecatedapenabled

Ich spiele gerade mit der neuen API die erst vor kurzem entwickelt wurde.
Früher konnte man die in den Einstellungen aktivieren, jetzt steht hier so was:

RemoteAPI.deprecatedapenabled

Das aktivieren geht. Die Frage aber ist, warum ist die schon wieder veraltet ?

[coalado]

Weil die API bald nur noch über unseren MYJDownloader Server erreichbar sein wird.

Okay danke für die Info. Habe im Forum gesucht aber da gibt es wohl noch keine Infos wie das ganze funktioniert oder eine Doku.

[thecoder2012]

Originally Posted by coalado

Weil die API bald nur noch über unseren MYJDownloader Server erreichbar sein wird.

Gibt es dafür einen besonderen Grund?

Ich bin wenig davon angetan das man einen fremden Server benötigt um die Funktion zu nutzen oder läuft es weiterhin auf dem eigenen Rechner/Server?

[coalado]

Hier gibt es eine Java Implementierung:

svn://svn.jdownloader.org/jdownloader/MyJDownloaderClient

Das neue Event System fehlt da aber noch.


Vorläufige Doku: http://goo.gl/i56SP

Auch da fehlt EventSystem, und das NotifySystem (Android/iOS) noch


Wer sich das etwas genauer ansieht, wird feststellen, dass der komplette Traffic verschlüsselt ist. Alles zwischen der einen Seite (Webinterface/Mobile App/...) Und dem JD zu Hause sieht nur Datensalat.

Wer Cryptofehler findet... bitte umgehend melden!


Warum:
Wir können so Remote Apps und Co entwickeln die jeder nutzen kann. Ohne Portforwarding und Co. JD braucht lokal keinen Webserver mehr offen haben (was eher gefährlich wäre, wenn die API mächtiger wird.)

Für LAN Traffic werden wir wohl noch einen Direct Mode einbauen. Aber das liefern wir nach.



der API Server ist gerade down. Wer Testen will, muss noch etwas warten.

[coalado]

API Server ist jetzt online, und auch auf my.jdownloader.org gibt es schon etwas zu sehen.

Danke für die Infos.
Wird es auch eine "Server" JDownloader Version geben die man nur über die MYJDownloader Server steuern kann? Also ohne GUI

[coalado]

Vermutlich ja

[oEFLKQzikCqw]

Originally Posted by coalado

Wer sich das etwas genauer ansieht, wird feststellen, dass der komplette Traffic verschlüsselt ist. Alles zwischen der einen Seite (Webinterface/Mobile App/...) Und dem JD zu Hause sieht nur Datensalat.

Die Verschlüsselung zwischen Webinterface (my.jdownloader.org) und JD ist aber für die Katz, wenn auf das Webinterface unverschlüsselt zugegriffen wird. In nicht vertrauenswürdigen Netzen (z. B, offene WLAN-Hotspots) würde ich das Webinterface auf my.jdownloader.org wegen der fehlenden Verschlüsselung nicht nutzen wollen.

Originally Posted by coalado

Ohne Portforwarding und Co. JD braucht lokal keinen Webserver mehr offen haben (was eher gefährlich wäre, wenn die API mächtiger wird.)

Warum sollte ein lokales Webinterface durch eine mächtigere API gefährlicher werden als ein Webinterface auf einem externen Server? Das Gefahrenpotential der API ist doch nicht davon abhängig, wo das Webinterface läuft. Allerdings bietet das Webinterface selbst zusätzliches Gefahrenpotential und da gibts dann schon einen Unterschied wo das läuft. Das ist aber nicht abhängig davon wie mächtig die API ist.

[coalado]

Die Verschlüsselung zwischen Webinterface (my.jdownloader.org) und JD ist aber für die Katz, wenn auf das Webinterface unverschlüsselt zugegriffen wird. In nicht vertrauenswürdigen Netzen (z. B, offene WLAN-Hotspots) würde ich das Webinterface auf my.jdownloader.org wegen der fehlenden Verschlüsselung nicht nutzen wollen.

MyJDownloader besteht im Grunde aus mehreren Komponenten.

• Statische Inhalte (Bilder, JS, HTML,..) werden von my.jdownloader.org geladen
• "Dynamische Inhalte" (Die Daten. Z.B. Downloadliste) werden verschlüsselt über api.jdownloader.org geladen

Für die Katz jetzt auch nicht unbedingt - Aber du hast recht.Die Dynamischen Inhalte über api.jdownloader.org sind sicher. Allerdings müssten die statischen Inhalte von my.jdownloader.org auch über eine gesicherte Leitung - z.B. SSL kommen. Vermutlich wird das auch so kommen.

die Dynamischen Inhalte sind durch die Poin-Point Verschlüsselung sicher und brauchen kein SSL - einziger Nachteil: Das Webinterface hätte kein "Grünes" SSL Icon.


Durch die Aufteilung in Statischen Content und Dynamische API Calls ist es natürlich auch jederzeit möglich die statischen Inhalte komplett Local zu haben. Sonderlich praktisch ist das aber natürlich nicht.



Ansonsten: Das Problem mit wenig vertrauenswürdigen Zugängen (Public WLAN...) besteht doch bei einem Webinterface das direkt von JDownloader kommt genauso, oder?

Warum sollte ein lokales Webinterface durch eine mächtigere API gefährlicher werden als ein Webinterface auf einem externen Server? Das Gefahrenpotential der API ist doch nicht davon abhängig, wo das Webinterface läuft. Allerdings bietet das Webinterface selbst zusätzliches Gefahrenpotential und da gibts dann schon einen Unterschied wo das läuft. Das ist aber nicht abhängig davon wie mächtig die API ist.

Eine "Lokale" API kann von vielen Browsern angesprochen werden. z.B. macht CNL das so. Moderne Browser blockieren solche CrossSite Requests zwar. Aber dennoch besteht das Risiko.
Eine "Füge Links hinzu, und frage mich aber vorher Funktion" ist wohl weniger kritisch als
"Füg einen Link hinzu, lad ihn runter, führ ihn aus und lösche den Downloadeintrag danach"

Das ist jetzt ein extremes Beispiel - Geladene Files ausführen wird selbst über MyJDownloader nicht möglich sein. Aber ich denke das ist verständlich.

[oEFLKQzikCqw]

Originally Posted by coalado

MyJDownloader besteht im Grunde aus mehreren Komponenten.

• Statische Inhalte (Bilder, JS, HTML,..) werden von my.jdownloader.org geladen
• "Dynamische Inhalte" (Die Daten. Z.B. Downloadliste) werden verschlüsselt über api.jdownloader.org geladen

Die Anmeldung bzw. das Login erfolgt dann wohl auch direkt am API-Server.

Originally Posted by coalado

Für die Katz jetzt auch nicht unbedingt - Aber du hast recht.Die Dynamischen Inhalte über api.jdownloader.org sind sicher. Allerdings müssten die statischen Inhalte von my.jdownloader.org auch über eine gesicherte Leitung - z.B. SSL kommen. Vermutlich wird das auch so kommen.

die Dynamischen Inhalte sind durch die Poin-Point Verschlüsselung sicher und brauchen kein SSL - einziger Nachteil: Das Webinterface hätte kein "Grünes" SSL Icon.

Der Nachteil ist eben nicht nur das fehlende SSL-Icon. Denn der unsichere statische Teil gibt einem Angreifer per MITM die Möglichkeit unbemerkt Inhalte auszutauschen oder unterzuschieben, über die er dann Zugriff auf die verschlüsselten dynamischen Inhalte bekommen kann (Hint: damit der Browser mit den Inhalten was anfangen kann, müssen sie entschlüsselt werden. Bei unsicheren Seiten besteht nahezu keine Chance einen MITM-Angriff zu bemerken. Bei durch SSL geschützten Seiten sieht das schon anders aus).

Genau aus diesem Grund reicht es auch nicht die Daten beispielsweise eines Loginformulars an eine sichere Seite zu schicken. Auch das Formular selbst muss sich auf einer sicheren Seite befinden.

Originally Posted by coalado

Ansonsten: Das Problem mit wenig vertrauenswürdigen Zugängen (Public WLAN...) besteht doch bei einem Webinterface das direkt von JDownloader kommt genauso, oder?

Ja und genau darauf wollte ich ja auch hinaus. Es macht in der Regel keinen Unterschied wo das Webinterface betrieben wird. Auch ein direkt von JD kommendes Webinterface kann man per SSL sichern.



my.jdownloader hat ein Problem mit dem Kontrast. Dunkle Schrift auf dunklem Hintergrund und helle Schrift auf hellen Hintergrund (Buttons) geht ja nun gar nicht. Wer soll so etwas lesen?

[coalado]

Die Anmeldung bzw. das Login erfolgt dann wohl auch direkt am API-Server.

Genau

Der Nachteil ist eben nicht nur das fehlende SSL-Icon. Denn der unsichere statische Teil gibt einem Angreifer per MITM die Möglichkeit unbemerkt Inhalte auszutauschen oder unterzuschieben, über die er dann Zugriff auf die verschlüsselten dynamischen Inhalte bekommen kann (Hint: damit der Browser mit den Inhalten was anfangen kann, müssen sie entschlüsselt werden. Bei unsicheren Seiten besteht nahezu keine Chance einen MITM-Angriff zu bemerken. Bei durch SSL geschützten Seiten sieht das schon anders aus).

Genau aus diesem Grund reicht es auch nicht die Daten beispielsweise eines Loginformulars an eine sichere Seite zu schicken. Auch das Formular selbst muss sich auf einer sicheren Seite befinden.

Wie gesagt. Wir wollen ja auch den statischen Teil über SSL bereitstellen.
Da diese SSL Seite dann aber mit einer non-ssl API kommuniziert, wird der Browser da eine Schwachstelle sehen - er kann ja nicht wissen dass die API verschlüsselt ist.

Also: Falls wir - wie geplant, den Statischen Teil über SSL bereitstellen, ist das SSL Icon(Es würde nicht fehlen. - nur anders aussehen) tatsächlich das einzige Problem.

Beispiel Facebook in Chrome:

So soll es aussehen:

Lädt Facebook externe - Non-SSL Inhalte schaut es dann so aus:



Unschön, aber aus Sicherheitssicht eigentlich kein Problem. Falls doch - klärt mich auf.

my.jdownloader hat ein Problem mit dem Kontrast. Dunkle Schrift auf dunklem Hintergrund und helle Schrift auf hellen Hintergrund (Buttons) geht ja nun gar nicht. Wer soll so etwas lesen?

Hast du eventl. einen Screenshot dazu?

[oEFLKQzikCqw]

Ach so, deswegen also "kein grünes SSL-Symbol" Es gibt da nur noch ein Problem, weder der Browser noch der JD können mangels SSL feststellen, dass sie tatsächlich mit dem richtigen Server verbunden sind und nicht etwa dem Server eines Angreifers, der per MITM untergeschoben wurde. Genaugenommen müsste man auch den API-Server per SSL absichern und sei es nur damit der Server sich gegenüber dem JD bzw. dem Browser zu authentifizieren. Allerdings weiß ich nicht, ob dieser Fall hier überhaupt ein Problem ist.


My.jdownloader.org sieht heute schon deutlich besser aus, was den Kontrast Schrift vs. Hintergrund angeht. Lediglich die Buttons lassen noch zu wünschen übrig, wobei mir so ist, als ob auch die schon verändert wurden.