Desktop-Applikation schreiben, wie daten persistent?

[OnDemand]

Hallo,

muss eine kleine Warenwirtschaft schreiben, welche rein vorsorglich schon mal als Client Server Applikation geschrieben wird .
Angenommen ich habe das Programm fertig mit einer Mysql auf dem lokalen pc (kann ja dann auch später innerhalb des Netzwerkes aufm Server laufen);
1. Frage:
Wie rolle ich das Programm aus? als ausführbare jar? (Find ich immer kritisch, wegen upps Datei gelöscht) Wir macht ihr das? DB muss ja lokal mit-installiert werden

2. Frage:
Wie rollt ihr Updates aus?

Freue mich auf eure praktischen Erfahrungen

 

[mrBrown]

Wie rolle ich das Programm aus? als ausführbare jar? (Find ich immer kritisch, wegen upps Datei gelöscht) Wir macht ihr das?

Java Web Start gäbe es noch, aber was spricht gegen direkt die jar? Wer das Programm löscht, besorgt es sich halt selbst...(Ist PC nutzen nicht schon zu gefährlich, wegen "ups, mit'm Hammer draufgeschlagen"? )

DB muss ja lokal mit-installiert werden

Nimm eine Datenbank, die ohne Server auskommt (HSQLDB, H2, ...), dann muss auch nichts installiert werden.

Wie rollt ihr Updates aus?

Gibt entsprechenden Frameworks dazu, einfach mal googlen

 

[Thallius]

Also wenn du eine lokale DB benutzen willst, dann solltest du sqlite nehmen. Da muss nichts installiert werden. Da kannst Du auch problemlos die .jar ausrollen. Wenn sie einer löscht dann muss er sie sich halt neu besorgen. Aber es muss nichts installiert werden, was ich persönlich als einen der größten Vorteile von Java sehen.

Mit einer lokalen DB wird aber natürlich eine Warenwirtschaft nicht funktionieren. Du must also so oder so eine DB auf einem Server aufsetzen. Ab da beginnen die ganz großen Problem. Nehmen wir an Client A ruft die Daten des Kunden X ab und zeigt sie in einem Fenster an, Client B ruft die gleiche Daten ab und zeigt sie ebenfalls in einem Fenster an. Nun ändert Client A die Daten und speichert si e ab, dann bekommt Client B das erstmal nicht mit und zeigt weiterhin germütlich die falschen Werte an. Ändert dieser jetzt die Daten auch und speichert sie ab, dann sind die Daten bei Client A hinfällig...
Du erkennst das Problem?

Updates liegen ganz einfach auf dem Server. Der Client frqagt per HTTP an einen Webservice ob es eine neue Version gibt und wenn ja, dann wird diese geladen. Das Ganze muss natürlich komplett abgesichert werden um sicherzustellen, dass das was auf dem Server liegt auch beim Client ankommt. Ich persöhnlich benutze dafür eine asymetrische AES Verschlüsselung. Der Client schickt dem Server einen mit dem public key verschlüsselten Salt. Der Server bildet aus dem Salt und dem Inhalt der Update-Datei einen Hash und schickt diesen zurück. Der Client empfängt die Update Datei zusammen mit diesem Hash und bildet seinerseits seinen eigenen Hash aus seinem Salt und dem Inhalt der Update-Datei. Sind beide Hash gleich, ist die Update-Datei unmanipuliert beim Client angekommen.

Gruß

Claus

 

[mrBrown]

Updates liegen ganz einfach auf dem Server. Der Client frqagt per HTTP an einen Webservice ob es eine neue Version gibt und wenn ja, dann wird diese geladen. Das Ganze muss natürlich komplett abgesichert werden um sicherzustellen, dass das was auf dem Server liegt auch beim Client ankommt. Ich persöhnlich benutze dafür eine asymetrische AES Verschlüsselung. Der Client schickt dem Server einen mit dem public key verschlüsselten Salt. Der Server bildet aus dem Salt und dem Inhalt der Update-Datei einen Hash und schickt diesen zurück. Der Client empfängt die Update Datei zusammen mit diesem Hash und bildet seinerseits seinen eigenen Hash aus seinem Salt und dem Inhalt der Update-Datei. Sind beide Hash gleich, ist die Update-Datei unmanipuliert beim Client angekommen.

Oder einfach: HTTPS nutzen?

 

[Thallius]

Oder einfach: HTTPS nutzen?

Das setzte ich sowieso vorraus. Aber auch da bist du nicht vor einem MITM Angriff sicher.

 

[Tobse]

Ich stimme @Thallius bezgl. der funktionalität zu: Das wird nicht einfach; die Updates per Versionsvergleich vom Server zu ziehen ist auch IMO der beste Weg.

Wenn du es richtig sauber angehen willst, setzt du einen Server auf und definierst Schnittstellen dafür. Das kann HTTP+REST (mit Json oder XML, etc) sein, oder SOAP, oder, oder, such dir was aus. Ich persönlich bin ein Fan von HTTP+REST mit JSON; damit erreicht man eine sehr hohe Kompatibilität; wenn später andere Anwendungen an das System angebunden werden sollen, ist das dann einfach.

Wenn deine Schnittstellen stehen, kannst du den Server programmieren, der die Schnittstellen bereitstellt. Und danach (oder parallel, je nachdem wieviel Manpower du abstellen kannst) den Client, der Sie nutzt, um mit dem Server zu kommunizieren. Auf dem Client speicherst du dann nurnoch solche Sachen wie lokale Einstellungen und ggf. ein Eingeloggt-Bleiben-Token.

Siehe dazu:
REST: https://de.wikipedia.org/wiki/Representational_State_Transfer
Design und Dokumentation der Schnittstellen: http://raml.org (benutze ich häufiger)
Und hier nochmal REST mit HTTP: http://www.restapitutorial.com

---

Offtopic:

Das setzte ich sowieso vorraus. Aber auch da bist du nicht vor einem MITM Angriff sicher.

Das bist du mit einem Custom Scheme erst recht nicht. AES ist symmetrisch. Keine Ahnung, was du da dazugebastelt hast, dass es jetzt asymmetrisch ist; aber die Wahrscheinlichkeit, dass ein einzelner da einen besseren Job als die TLS Autoren und die Crypto-Community machen kann, halte ich für verschwindend gering
Wenn du auf Nummer 100%-Sicher gehen willst, pinne dein Server-Zertifikat an den Client. Dann muss ein Angreifer deinen Private-Key bekommen, um ein MITM machen zu können. Stichwort "certificate pinning"

 

[Thallius]

Offtopic:


Das bist du mit einem Custom Scheme erst recht nicht. AES ist symmetrisch. Keine Ahnung, was du da dazugebastelt hast, dass es jetzt asymmetrisch ist; aber die Wahrscheinlichkeit, dass ein einzelner da einen besseren Job als die TLS Autoren und die Crypto-Community machen kann, halte ich für verschwindend gering

Ups sorry, war wohl noch bischen früh am Morgen. Meinte natürlich RSA und ich habe mir das Ganze gerade noch einmal angesehen (Ist schon länger her das ich das geschrieben habe) Es funktioniert noch wesentlich komplexer da ich damals für den Auftraggeber zu 100% sicherstellen musste, dass die Datei vom Entwickelungrecher auf dem sie erstellt wurde, bis hin zum Anwender-Rechner unter keinen Umständen manipuiert werden kann. Das musste auch einschliessen, dass der Upload zum Server und natürlich ein Hack desServers selber auch abgesichert sein mussten. Aber das würde zu weit führen das hier jetzt alles aufzubröseln.

Gruß

Claus

 

[OnDemand]

Moin, danke für eure Infos, ist aber etwas wie mit Kanonen auf Spatzen schießen Werd es mit einem Webservice machen, der Client prüft per Webservice ob die Lizenz noch aktuell ist und im gleichen Moment ob die Version noch neu ist.

@Thallius deine Anmerkungen mit der gleichzeitigen Datenmanipulation werde ich mit synchronized entgegenwirken und "Datensatz ist von UserXX in Bearbeitung, bitte später versuchen", das sollte reichen

 

[mrBrown]

@Thallius deine Anmerkungen mit der gleichzeitigen Datenmanipulation werde ich mit synchronized entgegenwirken und "Datensatz ist von UserXX in Bearbeitung, bitte später versuchen", das sollte reichen

syncronized wird bei Desktop-Clients nur wenig bringen, pro laufender Instanz gibt es ja nur jeweils einen Nutzer.

 

[OnDemand]

Recht hast du! Also den Datensatz sperren