Datei in DropBox schreiben

[Huitzlipochtli]

Hallo an alle,
ich würde für ein Programm gerne Dateien in meinem Public DropBox-Ordner laden und schreiben. Trotz googeln hab ich keine Ahnung wie ich das anstellen soll … Bisher hab ich für sowas File und FileWriter genutzt, aber Files können ja nur lokal auf dem Rechner verwendet werden. Das Programm ist eigentlich als JApplet geplant , aber ich weiß nicht ob das mit den Rechten klappt.

Hab im Moment echt keine Idee wie ich das angehen soll. ;( Danke für jede Hilfe

 

[Tomate_Salat]

Wie wäre es mit der Api?
https://www.dropbox.com/developers

 

[Huitzlipochtli]

Hmmm … Vielleicht stell ich mich n bisschen dämlich an, aber die API hilft mir grad nicht weiter. Da steht nur wie das mit Ruby und Python läuft. Mein Problem ist, dass ich in Java nicht weiß, wie ich auf nen Server schreiben soll, das Problem ist gar nicht mal DropBox spezifisch, würd nur gern DropBox dafür nutzen(könnte auch was anderes nutzen wenn nötig). Mir ist klar, dass ich mit nem Applet nicht auf einen Rechner schreiben kann, habe aber in "Java ist auch eine Insel" nicht gelesen, dass n Applet nicht auf ne öffentliche Seite schreiben kann.

 

[ARadauer]

aber in "Java ist auch eine Insel" nicht gelesen, dass n Applet nicht auf ne öffentliche Seite schreiben kann.

Was?
Nix kann auf eine öffentliche Seite schreiben. Was ist eine öffentliche Seite?

 

[Huitzlipochtli]

Ähhmmm … Ich mein eine HTML-Datei in einem öffentlichen DropBox-Ordner. Sorry für den Ausdruck .

 

[Huitzlipochtli]

Ich hab jetzt was gefunden, was in die Richtung geht die ich mir vorstelle, versuche jetzt eine Datei in Google Texte & Tabellen zu bearbeiten. Funktioniert aber leider nicht. Es gibt keine Fehlermeldung, aber in die Datei wird auch nicht geschrieben. Mache das eigentlich so wie in diesem Beispiel :Reading from and Writing to a URLConnection (The Java™ Tutorials > Custom Networking > Working with URLs)

 public static void htmlSchreiben(String inhalt) throws MalformedURLException, IOException
    {
        URL url = new URL("https://docs.google.com/document/d/hggkjhrjjk/edit");
        URLConnection connection = url.openConnection();
        connection.setDoOutput(true);
        OutputStreamWriter outstream = new OutputStreamWriter(connection.getOutputStream());
        outstream.write(inhalt);
        outstream.close();
    }

Ich weiß nicht, ob ich das falsch programmiert hab, oder ob das an Google T&T liegt. Die Datei ist öffentlich, der tatsächlich benutzte Link ist korrekt.

 

[irgendjemand]

es sollte auf jeden fall eine SecurityException fliegen ... da ein Applet ohne signatur nur verbindungen zu dem server aufbauen kann von dem es geladen wurde ...
so bald versucht wird eine verbindung zu einem anderen host aufzubauen wird blockiert ...

 

[Huitzlipochtli]

Ich muss das nicht unbedingt über DropBox oder Google T&T lösen. Kann mir jemand einen Ratschlag geben, wie ich das realisieren könnte?

Geplant ist ein JApplet(könnte aber auch Servlets nutzen), dass in eine HTML-Seite im Netz schreibt(am besten einfach nur append und nicht erst neues Dokument erstellen und hochladen), und das Informationen über seinen Zustand speichert und lädt(Serialisierung). Das App soll später meiner nPage-Seite laufen, dann könnte ich vielleicht auf deren Server schreiben.

Angenommen die Datei würde auf dem gleichen Server liegen, würde dann das hier funktionieren?

public static void htmlSchreiben(String inhalt) throws MalformedURLException, IOException
    {
        URL url = new URL("https://docs.google.com/document/d/aaaaa/edit");
        URLConnection connection = url.openConnection();
        connection.setDoOutput(true);
        OutputStreamWriter outstream = new OutputStreamWriter(connection.getOutputStream());
        outstream.write(inhalt);
        outstream.close();
    }

 

[Marcinek]

Du brauchst etwas auf dem Server, dass deine Daten annimmt und dann auf der Festplatte speichert.

Das könnte sein:

FTP
SSH
Ein einfaches Servlet
Ein Webservice
- REST

Ein blick in die Drop Box API zeigt mir, dass diese auch REST anbieten. Damit sollte es mit java trivial sein.


Gruß,

Martin

 

[Huitzlipochtli]

Würd lieber nicht auf ne Festplatte schreiben, sondern nur in ne Datei auf m Server. Geht das net ?

 

[Marcinek]

Du kannst auch die Änderungen im RAM abspeichern, aber das geht verloren, wenn der PC neu gestartet wird.

Wenn du nun in eine Datei auf dem Server speicherst, was glaubst du, wo die Datei dann gespeichert wird??

Dir fehlt jegliches Verständniss von Computern / Internet um diese Aufgabe zu lösen.

Was kann man nun machen? - Ich glaube am einfachsten ist es, wenn man das über FTP macht.
Da kann man sich von Apache ein FTP Client nehmen und dann die Datei auf einem FTP Server schreibt.

Wenn dann der FTP dies in ein Verzeichniss, das von einem Webserver dargestellt wird, schreibt, dann kannst du diese Seite auch einfach im Browser anschauen.

Hast du irgentwo überhaupt Webspace mit FTP zugriff? Ansonsten kannst du das ganze auch lokal auf deinem Rechner testen.

Fakt ist: So wie du das da oben machst, geht erstmal NICHT, es sein denn du hast auf der Gegenseite etwas, dass diese Daten in der Form verarbeiten kan (e.g. Servlet)

 

[Huitzlipochtli]

Hab bisher keinen Erfolg gehabt …

Versuche das im Moment auf Google Docs in ne öffentlich seh- und schreibbare Datei zu befördern.

 URL url = new URL("https://docs.google.com/document/d/aaaaaaaaa/edit-media");
        HttpURLConnection httpCon = (HttpURLConnection)url.openConnection();
        httpCon.setDoOutput(true);
        httpCon.setRequestMethod("PUT");
        OutputStreamWriter out = new OutputStreamWriter(httpCon.getOutputStream());
        out.write("Es klappt!");
        out.close();

Hier die Docs-API :
To update an existing document or file, first retrieve the entry to update, modify it as desired, and send a PUT request to either the edit link or the edit-media link, depending on what is to be updated. Use this method only to update metadata. This mechanism is not recommended for content updates, and may be deprecated in the near future. For content updates, instead use the resumable update mechanism, which is more scalable. If you are updating just a resource's metadata, use the edit link. If you are updating a resource's content, use the edit-media link. If you are updating both metadata and content, use the edit-media link. An example of these edit and edit-media links in an entry follows:

<entry xmlns:gd="http://schemas.google.com/g/2005" gd:etag="'HhJSFgpeRyt7ImBq'">
...
<title>PDF's Title</title>
...
<link rel="edit" type="application/atom+xml" href="https://docs.google.com/feeds/default/private/full/pdf%3A12345"/>
<link rel="edit-media" type="application/pdf" href="https://docs.google.com/feeds/default/media/pdf%3A12345"/>
...
</entry>

Ich weiß nicht, ob mein Fehler im Kern in der Nutzung von Java oder des API liegt.
Sollte vielleicht trivial sein, aber für mich ist es das im Moment nicht.
Hab im Netz keine hilfreichen Beispiele dafür gefunden.
Wichtig ist, das der Zustand nicht Nutzer-spezifisch persistent gemacht wird(z.B. mit Cookies oder so), sondern Eingaben im Applet erhalten bleiben, ganz egal welcher Benutzer grade das Applet lädt.
Ich würde das am liebsten so über Google Docs oder Dropbox lösen, ohne ein Servlet schreiben zu müssen.

Für konkrete Beispiele wäre ich unendlich dankbar.

Es dankt ein hoffnungslos verwirrter Anfänger

 

[irgendjemand]

Du kannst auch die Änderungen im RAM abspeichern, aber das geht verloren, wenn der PC neu gestartet wird.

Wenn du nun in eine Datei auf dem Server speicherst, was glaubst du, wo die Datei dann gespeichert wird??

Dir fehlt jegliches Verständniss von Computern / Internet um diese Aufgabe zu lösen.

Was kann man nun machen? - Ich glaube am einfachsten ist es, wenn man das über FTP macht.
Da kann man sich von Apache ein FTP Client nehmen und dann die Datei auf einem FTP Server schreibt.

Wenn dann der FTP dies in ein Verzeichniss, das von einem Webserver dargestellt wird, schreibt, dann kannst du diese Seite auch einfach im Browser anschauen.

Hast du irgentwo überhaupt Webspace mit FTP zugriff? Ansonsten kannst du das ganze auch lokal auf deinem Rechner testen.

Fakt ist: So wie du das da oben machst, geht erstmal NICHT, es sein denn du hast auf der Gegenseite etwas, dass diese Daten in der Form verarbeiten kan (e.g. Servlet)

das mit FTP ist jetzt nicht wirklich dein ernst oder ? *ich erinnere mal an die threads von Blackhole16 die sich genau DAMIT befassen* ...

@TO

wenn du willst das das applet daten im netzspeichert dann pack auf den server auf dem es liegt ein einfaches PHP-script das die daten in eine datenbank schreibt ... und die seite die dann mit nem anderen script angezeigt wird wird dann aus den db-daten on-the-fly erzeugt ...

aber einfach URL.openConnection() und dann da i-was writen geht sowieso nicht ohne das auf der anderen seite nicht zumindest ein script läuft was die daten animmt ...

btw : nichts auf platte schreiben : was meinst du wie ein server seine daten speichert ... bestimmt auch auf platten ...

und wie ich bereits sagte : ohne signatur kracht es eh erstmal eine reihe von SecurityExceptions ...

 

[Marcinek]

das mit FTP ist jetzt nicht wirklich dein ernst oder ? *ich erinnere mal an die threads von Blackhole16 die sich genau DAMIT befassen* ...

ja...

wenn du willst das das applet daten im netzspeichert dann pack auf den server auf dem es liegt ein einfaches PHP-script das die daten in eine datenbank schreibt

Wie unterscheidet sich dieses Konzept von dem von mir genannten via FTP Server?

 

[Huitzlipochtli]

btw : nichts auf platte schreiben : was meinst du wie ein server seine daten speichert ... bestimmt auch auf platten ...

Naja gut, dass die Datei letztendlich irgendwo auf nem Rechner landet weiß ich schon. Aber bei Google Docs kümmer ich mich nicht drum auf welchem. Gib halt nur den Account explizit an. So würd ich das auch am liebsten machen.

 

[irgendjemand]

Wie unterscheidet sich dieses Konzept von dem von mir genannten via FTP Server?

soll ich dir das jetzt wirklich noch mal alles aufzählen ?

in kurzform :
wenn ein client sich dierekt mit einem FTP verbinden soll müssen irgendwo die login-daten im client hinterlegt werden ...
zusätzlich braucht der FTP-acc WRITE-access ...

das beides zusammen und hast innerhalb von ein paar sekunden packet-sniffing ein fremdes warez-portal ums mal ganz krass auszudrücken

der unterschied zwischen direct-FTP und z.b. einem PHP-script als webservice sollte dir eigentlich klar sein
1) kein dierekter zugriff aufs file-system
2) möglichkeit die daten zu prüfen *syntax , gültigkeit , etc*
3) logging auf user-level *ein normaler user wird wohl kaum die FTP-logs seines hosters zu sehen bekommen ... mit einem php-script kann man selbst loggn*
4) speicher-ort : dem user kann es egal sein WO das script die daten speichert ... z.b. in einer datenbank oder speziellen container-files ... macht unter anderem auch die verwaltung einfacher

von daher ... um TO vor threads wie Blackhole16 von anfang an zu bewahren : das war echt der schlechteste tipp den du geben konntest ...

 

[Marcinek]

Danke für die Erläuterung. Das habe ich bisher nicht gewusst. [ironietag]

Dennoch ist das Konzept das gleiche. Wobei ein FTP server out of the box kommt, während so ein super toller abgeschirmter php webservice erstmal implementiert werden muss.

Weiterhin bietet mir all das auch schon ein FTP server, wie z.b. Filezilla an. Logging, Auth, zugriffsreche.

Weiterhin entspricht mein Vorschlag den Fähigkeiten und Bedürfnissen des TO. während dein Vorschlag beides übersteigt.

 

[HimBromBeere]

Einen FTP würde ich an der Stelle auch empfehlen, die Zugriffsrechte kann man ja auf ein spezielles Verzeichnis beschränken (notfalls auch noch mit Verbieten von Datei-Entfernungen o.ä.). Da muss er jedenfalls nicht erst haufenweise Implemntierungsaufwand reinstecken. Ob DropBox über´nen FTP geht, weiß ich nicht, verwende keines von beiden allzu oft (oder ganz genau annähernd nie^^)

 

[irgendjemand]

Danke für die Erläuterung. Das habe ich bisher nicht gewusst. [ironietag]

Dennoch ist das Konzept das gleiche. Wobei ein FTP server out of the box kommt, während so ein super toller abgeschirmter php webservice erstmal implementiert werden muss.

Weiterhin bietet mir all das auch schon ein FTP server, wie z.b. Filezilla an. Logging, Auth, zugriffsreche.

Weiterhin entspricht mein Vorschlag den Fähigkeiten und Bedürfnissen des TO. während dein Vorschlag beides übersteigt.

um noch mal explizit drauf hin zu weisen

da TO sagte das das ganze vermutlich fürs public bestimmt ist und somit vorraussichtlich mehr leute als nur er nutzen sollen wäre FTP wirklich die schlechteste wahl

1) Java unterstützt von aus haus nur sehr wenig dinge die mit FTP zu tun haben ... will man meher muss man sich es entweder selbst basteln oder eine LIB nutzen ...
alles was über HTTP läuft kann Java dagegen alles selbst ...

2) wenn ich software verteile die sich auf einen anderen server einloggt ... so muss ich dieser software die login-daten mitgeben ...
zusätzlich braucht der user auch entsprechende schreib-rechte wenn daten auf dem server gespeichert werden sollen ...
und wenn du so überzeugt bist das FileZillaServer da so gut gegen gerüstet ist ... dann erklär mir doch mal bitte wie man damit verhindern soll das ein user die login-daten ausliest *welche laut FTP text/plain übertragen werden müssen* ... sich mit z.b. dem FileZilla - client auf diesem einloggt und nun willkürlich daten hochläd ...
ich glaube kaum das du da viel machen kannst

mit einem simplen php-script kann man hier schon mehr erreichen ...
z.b. kann man die daten nach bestimmten mustern *vorzugsweise magic-numbers* scannen und bei fund einer unzulässigen sequenz einfach wieder vom löschen ... ohne das der client davon was mitbekommen muss *man kann ja trotzdem die meldung ausgeben : file uploaded ... was ja mit dem vollständigen senden des files an der server auch der fall ist ... was das user-script dann weiter mit diesen daten macht muss man ja nicht verraten
gut ... jetzt kann man natürlich kommen : nutz-daten verschlüsseln und in z.b. einem bild oder einer audio-datei tarnen ... aber es fällt auf wenn z.b. ein bild größer als 5MB-10MB ist ... oder auch eine audio-datei einige MB überschreitet *ich lasse WAV mal bewusst außen vor* ...
und sowas kann man z.b. auch prüfen ...
*man kann z.b. mit einem geeigneten backend die daten so scannen um den payload zu analysieren*

3) da als client ein java-applet eingesetzt wird würde sich auch ein java-backend anbieten ... *um mal nicht zu sehr auf PHP zu fixieren*
dadurch kann man ein eigenes protocol und verarbeitung der daten einbringen ... wodurch sich z.b. syntax-checks anbieten ... oder man auch mit JCE die verbindung leicht mit AES128-CBC sichern kann ...
ein "angreifer" müsste dann also erstmal dort "einbrechen" *gerade in verbindung mit RSA* ... was dann schon den aufwand zum "knacken" so weit erhöt das der nutzen den man daraus ziehen würde diesen aufwand vermutlich nicht mehr lohnt ...

4) ob jetzt drop-box oder FTP ... unsicher ist alles so lange im clienten irgendwelche login-informationen mit ausgeliefert werden ...
und genau dafür hat man das webservice-pattern ... eine schicht die ohne dierekten zugang zum server nicht *bzw nur sehr schwer* manipuliert werden kann ... aber dennoch einen "public" datenaustausch ermöglicht ... was das ganze um längen sicherer macht ...

so ... und jetzt möchte ich bitte mal argumente hören warum FTP in diesem fall einfacher wäre ...
zu erinnerung :
1) für FTP bräuchte man eine LIB bzw hätte viel schreibarbeit ... würde bei HTTP entfallen ...
2) login-daten werden preisgegeben
3) FTP-Server können nur schlecht gegen das einschleusen manipulierter daten geschützt werden
4) aufwand zur "sicherung" ist größer als der nutzen der "sicherheit" und bietet damit eine größere angriffsfläche ... bei einem webservice würde es sich umgekehrt verhalten : mit relativ wenig aufwand große sicherheit erzielen

 

[Marcinek]

Natürlich ist das, was du sagst nicht unbedingt falsch. Jedoch unvollständig und leider auch nicht dem Thread entsprechend, wie bereits zuvor festgetstellt.

Das Public in diesem Fall bezieht sich auf ein Public Verzeichnis von Dropbox, dass von jedem gelesen werden kann.

1) Java unterstützt von aus haus nur sehr wenig dinge die mit FTP zu tun haben ... will man meher muss man sich es entweder selbst basteln oder eine LIB nutzen ...
alles was über HTTP läuft kann Java dagegen alles selbst ...

Würde ich so nicht unterschreiben. Ich behaupte, dass man auch mit dem, was Java so bietet wunderbar mit einem FTP kommunizieren kann.

2) wenn ich software verteile die sich auf einen anderen server einloggt ... so muss ich dieser software die login-daten mitgeben ...
zusätzlich braucht der user auch entsprechende schreib-rechte wenn daten auf dem server gespeichert werden sollen ...
und wenn du so überzeugt bist das FileZillaServer da so gut gegen gerüstet ist ... dann erklär mir doch mal bitte wie man damit verhindern soll das ein user die login-daten ausliest *welche laut FTP text/plain übertragen werden müssen* ... sich mit z.b. dem FileZilla - client auf diesem einloggt und nun willkürlich daten hochläd ...
ich glaube kaum das du da viel machen kannst

Ohh und via HTTP werden Daten verschlüsselt übertragen? Sorry, du schreibst hier sachen, die einfach mist sind. Wieso muss ich die logindaten der software mitgeben, wenn diese sich auf einem Server einloggen soll? Und ist das bei einem HTTP Webservice anders? Und brauche ich beim HTTP Webservice keine schreibrechte? Aber wie soll ich dann Dateien hochladen? Und was hindert mich daran einen beliebigen Webservice Client zu schreiben und müll hochzuladen??

Hinweis: Diese Fragen sind retorisch zu sehen. Ich verstehe nur nicht, wieso du nicht merkst, dass beide Lösungen konzeptionell identisch mit nahezu den gleichen Möglichkeiten ausgestattet sind nur andere Technologien und Vereinbarungen nutzen.

mit einem simplen php-script kann man hier schon mehr erreichen ...
z.b. kann man die daten nach bestimmten mustern *vorzugsweise magic-numbers* scannen und bei fund einer unzulässigen sequenz einfach wieder vom löschen ... ohne das der client davon was mitbekommen muss *man kann ja trotzdem die meldung ausgeben : file uploaded ... was ja mit dem vollständigen senden des files an der server auch der fall ist ... was das user-script dann weiter mit diesen daten macht muss man ja nicht verraten
gut ... jetzt kann man natürlich kommen : nutz-daten verschlüsseln und in z.b. einem bild oder einer audio-datei tarnen ... aber es fällt auf wenn z.b. ein bild größer als 5MB-10MB ist ... oder auch eine audio-datei einige MB überschreitet *ich lasse WAV mal bewusst außen vor* ...
und sowas kann man z.b. auch prüfen ...
*man kann z.b. mit einem geeigneten backend die daten so scannen um den payload zu analysieren*

Obwohl ich keine Funktion von Filezilla kenne, dass das macht, ist das hier Aufwand, der niemals rechtfertigt zu sagen, dass ein HTTP Webservice hier die einzige Lösung ist. Wenn ich mein FTP Server so anpasse, erweitere, dass er das macht, dann macht er das auch. Aber dadurch, dass ich einen fertigen FTP Server nutze, habe ich mit 10 % aufwand 90 % meiner Anforderungen erfüllt.

Dieses Szenario ist total an den Haaren herbeigezogen und wird hier niemals angewendet werden. Und niemals ist das hier "simples php"

3) da als client ein java-applet eingesetzt wird würde sich auch ein java-backend anbieten ... *um mal nicht zu sehr auf PHP zu fixieren*
dadurch kann man ein eigenes protocol und verarbeitung der daten einbringen ... wodurch sich z.b. syntax-checks anbieten ... oder man auch mit JCE die verbindung leicht mit AES128-CBC sichern kann ...
ein "angreifer" müsste dann also erstmal dort "einbrechen" *gerade in verbindung mit RSA* ... was dann schon den aufwand zum "knacken" so weit erhöt das der nutzen den man daraus ziehen würde diesen aufwand vermutlich nicht mehr lohnt ...

Der TO hat keinen Server mit Java. Aber hauptsache hier mehr Text schreiben in der Hoffnung "Liest sich ehh niemand durch".

Selbst wenn, bis du das impementiert hast, habe ich mir 100 mal einen sftp server hingelegt und konfiguriert.

4) ob jetzt drop-box oder FTP ... unsicher ist alles so lange im clienten irgendwelche login-informationen mit ausgeliefert werden ...
und genau dafür hat man das webservice-pattern ... eine schicht die ohne dierekten zugang zum server nicht *bzw nur sehr schwer* manipuliert werden kann ... aber dennoch einen "public" datenaustausch ermöglicht ... was das ganze um längen sicherer macht ...

Der erste satz ist ja noch stimmig. Aber was danach kommt ist einfach nur müll. Sorry, wie unterscheidet sich der auth von einem HTTP und einem FTP? Die Schlussfolgerung ist einfach falsch. Und die Webservice Qualitäten zeichnen sich bei ganz anderen Dingen ab, nur nicht gerade das, was du hier Ausdrükcken möchtest.

so ... und jetzt möchte ich bitte mal argumente hören warum FTP in diesem fall einfacher wäre ...
zu erinnerung :
1) für FTP bräuchte man eine LIB bzw hätte viel schreibarbeit ... würde bei HTTP entfallen ...
2) login-daten werden preisgegeben
3) FTP-Server können nur schlecht gegen das einschleusen manipulierter daten geschützt werden
4) aufwand zur "sicherung" ist größer als der nutzen der "sicherheit" und bietet damit eine größere angriffsfläche ... bei einem webservice würde es sich umgekehrt verhalten : mit relativ wenig aufwand große sicherheit erzielen

1) FTP braucht man keine LIB. Es sei denn man will es sich sehr einfach machen. Und selbst dann, wäre die Verarbeitung von HTTP Daten ohne Libs viel aufwändiger.

2) Nein werden sie nicht. Wieso auch? Man richtet entsprechende User im FTP Server ein. Weiterhin trifft diese Einschränkung auch auf dein webservice zu. Hier würdest du auch von dem user die pws abfragen oder wo wären die dann?

3) HTTP Webservices, wenn es sich , wie hier, um Binärdaten handelt ebenso.

4) Nein. Einen gesicherten Webservice, wie du ihn ansprichst müsste man sich auch iwo fertig downloaden. Jede eigene Implementierung wäre nicht so gut, wie die eines Teams, dass sich nur damit beschäftigt. Hier würde man ein Axis oder Axis2 Framework nutzen müssen. Wären man so ein FTP Server nur downloadet und startet. Ansonsten hast du die Sicherung auf dem Transportlayer und nicht application.

Zusammenfassend: Die korrekte Lösung für dieses Problem ist die nutzung eines FTP Servers, der Zugriff auf einen durch einen apache oder anderen Webserver gelesenen Verzeichnis mit directory listing hat. Ein Webservice übersteigt den Aufwand des nutzenz um manipulierte binärdaten um ein vielfaches. Und hat keine Vorteile gegenüber einem FTP Server. (in diesem fall).

 

[irgendjemand]

sorry wenn ich dir das so dierekt an den kopf werfe ... aber du bist scheinbar genau so dumm wie Blackhole16 ... der es ja auch nicht einsehen wollte das FTP zu unsicher ist ...

dessweiteren : mit dem PUBLIC was ich meine war NICHT das public-directory von dropbox gemeint ... sondern der fakt das TO dieses applet anderen zur verfügung stellen will ...

klar kann man mit java auch 100% FTP ... allerdings ist man dann darauf angewiesen alles selbst mit Sockets und Streams zu machen und das protocol selbst zu implementieren ...
was ich meinte war das HTTP 100% unterstützt wird *durch die klasse HttpURLConnection* ... FTP hingegen maximal soweit das man *wenn überhaupt* daten von nem FTP lesen kann ... draufschreiben geht ohne LIB bzw eigenen code NICHT

thema crypto : mir ist bewusst das HTTP und FTP beide text/plain sind ... und das man beide auch über SSL/TLS sichern kann ...
ftp dazu sogar noch über SSH ...
ABER : HTTP+SSL wirst du sicher schneller finden als S/FTP/S ... zumindest wenn du nicht gleich einen eigenen (v)Server mieten willst

zu den login-daten : wer sagt das man sich im web-service einloggen muss ? man schreibt einfach ein PHP-script was die HTTP POST daten verarbeiten ... FERTIG ...
wenn sich allerdings *und jetzt lies das hier mal bitte richtig* sich der client DIEREKT mit dem server verbindet dann MUSST du die FTP-login-daten im client hinterlegen ...
und genau DAS ist das größte , aber auch am einfachsten zu schließende sicherheitsloch ... aber du bist scheinbar unfähig das zu begreifen ...

ergo : da du scheinbar auch die andren threads in denen es um genau das hier *das speichern von user-daten auf einem server* ging ... und es hier scheinbar auch immer noch nicht verstehst ... unterlasse es bitte dem TO zu liebe solche schwachsinnigen hinweise zu geben ...

ansonsten folgt genau das was ich bereits Blackhole16 sagte : gib mir deine software und innerhalb von 2min mach ich da n warez-portal draus ...

 

[gasssssst]

Ihr seid beides echt zwei riesen ****** mit zu großen Egos...

/thread (der, eigentlich schon mit der ersten Antwort beendet war)

 

[HoaX]

zu den login-daten : wer sagt das man sich im web-service einloggen muss ? man schreibt einfach ein PHP-script was die HTTP POST daten verarbeiten ... FERTIG ...
wenn sich allerdings *und jetzt lies das hier mal bitte richtig* sich der client DIEREKT mit dem server verbindet dann MUSST du die FTP-login-daten im client hinterlegen ...
und genau DAS ist das größte , aber auch am einfachsten zu schließende sicherheitsloch ... aber du bist scheinbar unfähig das zu begreifen ...

Nö, es soll auch FTP-Server geben die Anonymous-Benutzer zulassen, und man kann auch Benutzern verschiedene Rechte geben, z.B. nur schreiben, aber nichts auflisten, lesen, löschen, etc ... ich sehe da keinen Unterschied. Scheinbar bist du nicht in der Lage zu begreifen dass es noch eine andere Welt außer "deiner" gibt. Schonmal einen FTP-Server konfiguriert? Nein, bitte nicht antworten...

ergo : da du scheinbar auch die andren threads in denen es um genau das hier *das speichern von user-daten auf einem server* ging ... und es hier scheinbar auch immer noch nicht verstehst ... unterlasse es bitte dem TO zu liebe solche schwachsinnigen hinweise zu geben ...

Also der größte Schwachsinn kommt ja wohl in diesem Thread immernoch von dir. Null Toleranz, gemecker ohne Ende, und immer die Nase ganz weit oben. Ich würde hier zwar auch das ein oder andere anders machen, aber keine der genannten vorgehensweisen ist von Haus aus falsch, sie ziehen nur je nach Anwendungsgebiet entsprechende weitere Maßnahmen nach sich. Und wenn zu den Einsatzbedingungen nichts genannt wird, dann ist das so, dann ist alles richtig, nicht nur das was du in deiner Vorstellung für richtig hälst und rein interpretierst.

Und wenn wir schon bei Forderungen sind: Lass es gefälligst andere hier öffentlich als "dumm" etc. zu betiteln. Es hat dir niemand etwas getan. Würdest du mal anfangen mehr zu denken vor dem Posten, und weniger wild irgendwas nach deinem belieben zu interpretieren, und sachlich bleiben würdest, dann würden dir hier sicherlich auch viele Mitglieder anders in ihren Posts antworten.

 

[Marcinek]

sorry wenn ich dir das so dierekt an den kopf werfe ... aber du bist scheinbar genau so dumm wie Blackhole16 ... der es ja auch nicht einsehen wollte das FTP zu unsicher ist ...

Wenn einem keine Argumente mehr einfallen ;D / Ganz erhlich da stehe ich drüber und halt meine Nase hoch ^^:bae:

klar kann man mit java auch 100% FTP ... allerdings ist man dann darauf angewiesen alles selbst mit Sockets und Streams zu machen und das protocol selbst zu implementieren ...
was ich meinte war das HTTP 100% unterstützt wird *durch die klasse HttpURLConnection* ... FTP hingegen maximal soweit das man *wenn überhaupt* daten von nem FTP lesen kann ... draufschreiben geht ohne LIB bzw eigenen code NICHT

Angenommen es ist so, wie du sagst. Was würde gegen eine weitere Lib sprechen?

zu den login-daten : wer sagt das man sich im web-service einloggen muss ? man schreibt einfach ein PHP-script was die HTTP POST daten verarbeiten ... FERTIG ...
wenn sich allerdings *und jetzt lies das hier mal bitte richtig* sich der client DIEREKT mit dem server verbindet dann MUSST du die FTP-login-daten im client hinterlegen ...
und genau DAS ist das größte , aber auch am einfachsten zu schließende sicherheitsloch ... aber du bist scheinbar unfähig das zu begreifen ...

Das ist einfach schlicht weg falsch. Ich kann mich mit Java gegen ein FTP authentifizieren und muss das auch an dem HTTP Webservice machen. Und in beiden Fällen muss ich nix von PWs im Code hinterlegen. Wenn man nun nicht versteht, wie das geht (UserInteraction), dann sollte man nun anfangen für ein binärfile ein webservice zu schreiben mit PHP...

ansonsten folgt genau das was ich bereits Blackhole16 sagte : gib mir deine software und innerhalb von 2min mach ich da n warez-portal draus ...

Los mach: Hier ist mein Client / Server

FileZilla - The free FTP solution

Mach ein Warezportal draus.Uhhh... Aber halt ich kann mich mit meinem Filezilla Client nicht am FTP Server authentifizieren, weil die pws im Client abgelegt sind -.- Und jeder FTP Server hat das gleiche PW ^^

Du solltest mal reflektieren, was du hier schreibst.