Java Server - IOS Client Applikation

[Argonox]

Hallo zusammen,

Ich bin derzeit dabei, eine Java Server <> IOS Client (später auch Web-Clients) Applikation zu konzeptionieren.

Ich bin mit den Technologien noch nicht wirklich vertraut, möchte mich aber ungern in etwas reinarbeiten um im nachhinein festzustellen, dass ich auf einem komplett falschen Pfad bin.

Was für mich noch nicht hundertprozentig klar ist, betrifft die Kommunikation zwischen IOS und Java Server.

Folgender Plan:

IOS APP mit JSON Schnittstelle <> Java Servlet auf JSON(GSON) Basis <> Java Applikation <> PostgreSQL Server

klingt das für euch vernünftig?

vielen Dank und beste Grüße,
Argonox

 

[Bizarrus]

Imprinzip bist du schon auf dem richtigen weg.
Ich selber habe bereits ein Chatsystem erstellt gehabt, was auch über iOS läuft.

Java-Seitig wäre es am besten, du arbeitest mit Sockets. Ich selber arbeite über Bytebasierten Sockets, es werrden halt Byte-Arrays versendet und empfangen.

Unter iOS könnte ich dir später mal einige Beispiele senden, bin aber gade in einem Meeting 😛

 

[Argonox]

Hallo Bizarrus!

vielen Dank schonmal dafür 🙂.

Gerne, Beispiele sind natürlich immer willkommen 🙂

Zu den "Sockets":
Ich habe mal gelesen, dass man es sich mit Bytebasierten Sockets unnötig kompliziert macht? Wie siehst Du das?

Desweiteren plane ich ja zu einem späteren Zeitpunkt auch einen Web-Client (JQUERY/AJAX) anzubinden und denke daran, die gleiche Schnittstelle wie für IOS zu nutzen.

Dann hätte ich noch die Sorge, dass es dann zu Firewall Problemen kommen könnte.

besten Dank und Grüße,
Argonox

 

[Bizarrus]

Hallöle 🙂
Bin leider noch nicht zuhause, sonst hätte ich dir schon etwas zusammen gestellt - Mein Macbook liegt leider zuhause 😛

Ich habe mal gelesen, dass man es sich mit Bytebasierten Sockets unnötig kompliziert macht? Wie siehst Du das?

Das kommt immer darauf an, was man genau machen möchte und in wiefern man Erfahrungen mit den Themen gesammelt hat.

Desweiteren plane ich ja zu einem späteren Zeitpunkt auch einen Web-Client (JQUERY/AJAX) anzubinden und denke daran, die gleiche Schnittstelle wie für IOS zu nutzen.

Das wäre dann zum beispiel schlecht, hier Sockets zu verwenden.
Warum nutzt du dann nicht einfach etwas anderes? Beispiel wäre PHP.
Es wäre viel einfacher die Daten direkt mit einem Webserver hin und her zu schieben, wenn du ohnehin schon vor hast Webbasiert damit arbeiten zu wollen.

Denn du müsstest nun weiter denken: Dein "Java Server" müsste ohnehin alle die Funktionen implementiert haben, Plaintext in Form von JSON auszugeben. Ob du nun einen kleinen Webserver über Java schreibst, der das gleiche macht wie dein Webspace/Server wäre also unnötige Zeitverschwendung.

Dann hätte ich noch die Sorge, dass es dann zu Firewall Problemen kommen könnte.

Diese Bedenken kann ich leider nicht teilen. Ob nun Anfragen über den Webserver laufen oder über Sockets ist irrelevant, schon alleine weil die Verbindung ohnehin bestehen muss. Gut, was vllt. sein kann ist, dass du Lokal die Ports nach außen öffnen müsstest, sofern du ein eigenen Server schreiben möchtest.

 

[Hotspott]

Ich kann leider kein Objectiv C für iOS Apps, aber auch Apple wird Frameworks haben um direkt mit einem SQL Server zu kommunizieren aus einer App hinaus.

Also ist doch der naheliegenste weg wenn du auch noch ein Webinterface haben willst:

iOS App <> SQL Server <> Webinterface

 

[TKausL]

Natürlich und 2 wochen später hat jemand die Verbindung mitgesnifft und manipuliert deine DB...

 

[Templarthelast]

Ich finde Webservices wie Rest wesentlich leichter und angenehmer als Sockets bzw. Servlets und mit Rest hättest du die Möglichkeit mit der gleichen Backendstruktur android-/web-Applikation zu erstellen.

 

[Bizarrus]

Wie TKausL bereits sagt:
Man verwendet NIEMALS eine direkte Datenbank-Verbindung bei Clients.

Zwar können iOS Apps noch nicht "dekompiliert" werden, sondern nur "disassembled" werden, aber das Mitsniffen wäre eine möglichkeit an einer bestehenden MySQL-Connection teilzunehmen.

Ganz anders würde es mit Android auf Java-Basis aussehen, denn Java kann generell dekompiliert werden, selbst wenn durch einige Verschlüsselungsmethoden/Protecting die Source "unleserlich" kompiliert wird. Bei derartige verfahren wird auch nur das Dekompilieren etwas erschwert, was allerdings keinen daran hindern würde, die MySQL-Daten zu erforschen.

Der simpleste Weg wurde ja bereits von mir genannt: Man nehme ein Webserver (Der vllt. so oder so schon zur verfügung steht) und lässt die Daten via JSON hin und her rutschen. Dies ist die einfachste und vor allem Leistungsärme Methode.

Du musst ja auch daran denken, dass man eventuell mobil surft und kein WiFi Netzwerk in der nähe hat.
Da wäre ein Datenaustausch über XML Beispielsweise wiederrum zu groß, schon alleine weil ein XML-Dokument eine vielzahl mehr an Daten ausgibt (Die ganzen Tags & co).

 

[Argonox]

Hallo zusammen!

zum Thema PHP oder Java:
Ziel ist es, eine kleine ERP Anwendung (bis zu 100 clients) zu entwickeln. In Zukunft soll es auch um Schnittstellenmodule erweitert werden, welche beispielsweise auch das Anbinden von Barcode Scannern ermöglichen soll.

Mir sind Performance, Sicherheit und Wartbarkeit wichtig. Mein Gefühl sagt mir, dass ich in dem Fall besser mit Java fahre als mit PHP. Aber das ist nur ein Gefühl und hoffe, dass ihr mir aus Erfahrung sagen könnt, was in dem Fall geeigneter ist.

Warum keine direkte SQL Anbindung:
Sicherheitsrisiko... Des weiteren soll es eine klare Trennung von User-Interface und Anwendungslogik geben.

beste Grüße,
Argonox

 

[Hotspott]

Aber ein socket kann man genauso sniffen, genauso wie alles andere was durch ein Netzwerk geht. Da ist von de Sicherheit her kein Unterschied zu allen anderen Methoden. Natürlich sollte man mit Verschlüsselungen arbeiten, wenn man etwas sicheres auf die Beine stellen will.

 

[TKausL]

Aber ein socket kann man genauso sniffen, genauso wie alles andere was durch ein Netzwerk geht. Da ist von de Sicherheit her kein Unterschied zu allen anderen Methoden. Natürlich sollte man mit Verschlüsselungen arbeiten, wenn man etwas sicheres auf die Beine stellen will.

Bei einem Socket kann der Server aber entscheiden ob eine anfrage zulässig ist oder nicht, bsp. einen punktestand eintragen. Der SQL-Server würde allerdings ein DELETE FROM table; einfach so durchlassen.

 

[Hotspott]

Doch das kann er, auch für SQL gibt es Benutzer und Benutzergruppen. SQL ist weit aus umfangreicher als manche denken. So kann man einen Admin anlegen und ein Benutzer welcher nur Insert und Select darf und durch diesen greift die App zu. In Kombination mit einer Verschlüsselten Verbindung sollte das doch reichen oder nicht?

P.S. Eine Verbindung zu einem SQL Server ist ja auch nur ein Socket.

 

[tröööt]

@Hotspott
du rallst das nich was hier in punkto sicherheit scheif gehen kann oder ?

wenn man dem clienten einen sql-user direkt mitgibt kann man mit diesem alle ops durchführen die der server zulässt ...

alleine der punkt datenbank-verbindungen von außerhalb zuzulassen stellt schon ein enormes risiko dar ... darum sollte in der host-liste eh nur "localhost" stehen um verbindungen von außen gänzlich zu unterbinden ... und natürlich auch firewall nach außen hin dicht machen ... und stattdessen immer einen webservice nutzen

und auch wenn man einen sql-user stark einschränkt (als ob wir hier davon reden dem client ROOT zu geben) bleibt ein rest-risiko statements auszuführen die so nicht gewollt sind ... und der sql-server selbst kann hier nicht eingreifen ...

sowas geht dann eher nur mit zwischen-services die die anfrage auch prüfen ob diese auch so gültig ist ... natürlich muss hier auch gegen sql-injection vorgesorgt werden ... aber das ist relativ einfach ...

 

[Hotspott]

Ne versteh ich momentan auch nicht. Wofür gibt es die Funktion in SQL dann? Ich meine so ist der Unterachied zu einem WebService der auch nur den Benutzer identifiziert und dementsprechende rechte vergibt.

 

[trööt]

gut ... wenn du nicht verstehst warum es ein solches sicherheitsrisiko ist direkt eine SQL-verbindung zu nutzen frag mal google ... es gibt genug beispiele ...

und selbst wenn du es komplett einschränkst das ein user z.b. nur SELECT aus einer bestimmten tabelle einer bestimmten datenbank lesen darf ... so kann man mit diesem dann aber immer noch ALLES lesen was eben in genau dieser tabelle steht ... was gerade bei multi-user software schwer wird wenn du nicht unbedingt für wirklich jeden user des systems einen eigenen sql-user mit eigener datenbank/tabelle anlegen willst ... und selbst dann bliebe noch ein gewisses rest-risiko durch fehler in der datenbank selbst ...

webservices nutzt man in der regel genau dann wenn der client lediglich ein paar parameter ans backend übergeben soll das dann für ihn die entsprechenden informationen aus der datenbank liest und ihm zur verfügung stellt ...

ich glaube du stellst dir das alles etwas zu einfach vor ...
stell dir doch nur mal alleine facebook (bzw dessen smartphone-app) vor ...
wenn jede dieser apps einen direktzugang zur datenbank hätte ... dann bräuchte facebook auch entsprechend viele datenbank-user mit speziellen rechten ...
alleine die kommunikation zwischen zwei personen wäre äußerst schwierig ... auch wenn es zwischen INSERT und DELETE einen unterschied gibt (obwohl beides schreibend ist) ...
außerdem müsste man dann für jede verknüpfung von person zu person extra tabellen anlegen ... und so weiter und so fort ...
würde man es wirklich so umsetzten würde man damit die datenbank aber so schnell in die knie zwingen das es bei der wachstumsrate von facebook nicht mal möglich wäre rechtzeitig neue resourcen bereitzustellen ...

deutlich einfacher ist es wenn facebook hier als zentraler webservice dient und ledilglich ein paar parameter des users entgegen nimmt um z.b. einem freund eine pn zu schreiben ...

mag sein das es vielleicht bei 5 oder 10 usern nicht auffällt ... aber spätestens ab einer gewissen grenze wird es zu komplex ...

 

[Hotspott]

Ja klar für noch wieviele Tausende User ist das keine gute Lösung.
Ich gebe mich geschlagen. War ja nur ein Vorschlag für eine schnelle Lösung bin nicht von so vielen Usern die Saatsgeheimnise austauschen, aus gegangen 😉

 

[Templarthelast]

Ja klar für noch wieviele Tausende User ist das keine gute Lösung.
Ich gebe mich geschlagen. War ja nur ein Vorschlag für eine schnelle Lösung bin nicht von so vielen Usern die Saatsgeheimnise austauschen, aus gegangen 😉

Es muss ja nur einen geben, der Lust auf ein bisschen SQL Injection hat und dir dardurch deine Anwendung abschiest....

 

[Hotspott]

Ich glaub leider immernoch an das gute im Menschen, manchmal eine Schwäche, manchmal eine Stärke. 🙂

 

[Templarthelast]

Es ist einfach nur Dumm. Genauso wie keinen Zaun gegen Einbrecher zu bauen, weil es ja sowieso noch nie passiert ist bzw. das doch sowie so keiner macht. Ich will jetzt nicht die ganze Menschheit schlecht machen, aber man muss für alle Fälle vorkehrungen treffen.

Frei nach dem Motto: Auf das schlimmste Vorbereitet sein und auf das Beste hoffen.

 

[Bizzi]

Wow, da überlegt jemand nicht. Weiter oben sagte jemand, warum SQL überhaupt für Java angeboten wird. Überlg mal: Es gibt nicht nur hirnrissige Programme, die direkt auf SQL zugreifen...

Genauso kann man auch komplexe Server/Clientarchitekturen verwenden, wo NUR serverseitig SQL zur verfügung steht, warum? Security!

Man darf ruhig schon mal genauer überlegen. Bloss derartie Themen sind komplex, schon alleine für anfänger.

Tatsache ist: Datenbankverbindungennwerden AUSSCHLIESSLICH Serverseitig angewendet. Zu keinem Zeitpunkt darf der Client auf die Datenbank zugreifen. Mögliche SQL-Querys werden immer ausschliesslich Serverseitig behandelt.

 

[tröööt]

Wow, da überlegt jemand nicht. Weiter oben sagte jemand, warum SQL überhaupt für Java angeboten wird. Überlg mal: Es gibt nicht nur hirnrissige Programme, die direkt auf SQL zugreifen...

Genauso kann man auch komplexe Server/Clientarchitekturen verwenden, wo NUR serverseitig SQL zur verfügung steht, warum? Security!

Man darf ruhig schon mal genauer überlegen. Bloss derartie Themen sind komplex, schon alleine für anfänger.

Tatsache ist: Datenbankverbindungennwerden AUSSCHLIESSLICH Serverseitig angewendet. Zu keinem Zeitpunkt darf der Client auf die Datenbank zugreifen. Mögliche SQL-Querys werden immer ausschliesslich Serverseitig behandelt.

QFT