App mit Anbindung an Webservice / Webseite: Grundlagen, Techniken, etc.

  • App mit Anbindung an Webservice / Webseite: Grundlagen, Techniken, etc.

    Hallo,

    bei einem Gespräch mit einem Kollegen ging es um die Möglichkeiten eine App mit einem Webangebot zu koppeln. Dabei musste ich feststellen, dass ich spontan keine konkrete Idee hätte, wie ich das umsetzten würde. Ich habe schon Apps entwickelt und auch schon Webseiten erstellt. Aber bei der Frage wie ich beide Welten koppeln würde, bin ich dennoch ziemlich unsicher.

    Es ging um ein Projekt für die Vertragsverwaltung von Außendienstmitarbeitern. Die Außendienstler sollten Unterwegs über eine App auf bestehende Kunden- und Vertragsdaten zugreifen können, neue Datesätze erstellen, etc. Wichtig dabei: Die Arbeit muss in jedem Fall offline erfolgen können. Gleichzeitig lässt sich das System auch vor Ort im Intranet der Firma nutzen wo es als Webseite/Webanwendung läuft. Dort ist die permanente Verbindung zu den Daten natürlich kein Problem.

    Die App muss Unterwegs offline laufen -> Eine App die nur ein besserer Browser ist und zur Darstellung einer mobilen Version der Webseite verwendet wird ist keine Lösung. Die App muss Daten selbst speichern und verarbeiten können. Verträge müssen auch ohne Verbindung zur Webseite geprüft und aufgerufen werden können, etc. Es müsste sich also um eine native App mit eigener Funktion und Logik handeln die nur Daten mit der Webseite austauschen und synchronisieren kann.

    Aber wie würde man die Verbindung von App und Webseite herstellen? Was ist dabei Best Practice? Klar, die App kann die Webseite über HTTP erreichen, aber ist das wirklich der beste Kanal zwischen App und Webseite? In welchem Format werden die Daten übertragen (XML, JSON, ...?) Wie Sichert man die Übertragung. Und und und...

    Ich habe noch keinerlei Erfahrung im Zusammenspiel von Webseiten/-diensten und nativen Apps. Gleichzeitig ist das alles andere als neu. Wenn also damit schon jemand Erfahrung sammeln konnte und mir ein paar Brocken und Stichworte hinwerfen kann, wäre das wirklich super.

    Vielen Dank!

  • Ich würde ein Webservice schreiben, über welche deine iOS App mittels NSURLSession und die Website über AJAX die Daten bezieht. Ich würde JSON nehmen (besser von Javascript unterstützt und weniger Overhead als bei XML).

  • Sicher nicht die alleinige Wahrheit, aber wie ich es machen würde:

    Betrachte die App und die Webseiten im Intranet als zwei unterschiedliche GUIs, die sich auf die gleiche Datenbasis stützen. Also verbindet sich die App nicht mit den Webseiten (oder nutzt diese), sondern sie kontaktiert den gleichen Datenbank-Server, der (hoffentlich) auch die Web-Applikation bedient.

    Da es keine gute Idee ist, über ein öffentlicheres Netz direkt mit einem DB-Server zu kommunizieren, nutzt Du dafür z. B. einen Web-Service, der die Daten als JSON o. ä. liefert. Und um eine Offline-Nutzung zu ermöglichen, cachst Du diese Daten bzw. synchronisiert die App-Daten mit dem Web-Service periodisch.

    Also:

    DB --- Web-Service --- Offline-Cache --- App

    bzw.

    DB --- Intranet-Webapplikation

    Das ganze hängt aber sehr von den Gegebenheiten ab, und von dem Umfang, in dem Du Einfluss auf die Umgebung hast.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Datenbank <-> Webservice <-> JSON <-> APP

    Es lässt sich mit einem Webservice, z.B. via PHP so ziemlich jegliche Kommuniklation zwischen APP und Webseite/Datenbank realisieren. Wichtig ist dabei die sichere Übertragung der Daten, mit und ohne Authentifizierung.
    Ich bin gegen Signaturen!!!

  • markusschalk schrieb:

    beage schrieb:

    markusschalk schrieb:

    Ich würde das Webservice auf einen internen Server hosten und der Außendienstmitarbeiter greift mit der App via VPN darauf zu.
    Aus welchem Grund?
    Sicherheit
    Ich kann einen Webservice auch so sicher erstellen, ohne dass der im lokalen Netz gehostet ist. Der Außendienstler kann auch so per VPN auf den Server zugreifen. Aber warum überhaupt VPN? Sag jetzt aber nicht wieder "Sicherheit".
    Ich bin gegen Signaturen!!!

  • beage schrieb:

    markusschalk schrieb:

    beage schrieb:

    markusschalk schrieb:

    Ich würde das Webservice auf einen internen Server hosten und der Außendienstmitarbeiter greift mit der App via VPN darauf zu.
    Aus welchem Grund?
    Sicherheit
    Ich kann einen Webservice auch so sicher erstellen, ohne dass der im lokalen Netz gehostet ist. Der Außendienstler kann auch so per VPN auf den Server zugreifen. Aber warum überhaupt VPN? Sag jetzt aber nicht wieder "Sicherheit".
    das wort "lokal" war wohl etwas ungeschickt gewählt. der server sollte halt im gleichen netz stehen wie der DB-server (eventuell ist es sogar der gleiche server).
    Aber was würdest du anstelle VPN verwenden? etwa einfach nur HTTPS für jeden nach ausen hin öffnen sodass jedes script-kiddie mal darauf angriffe starten kann (dass HTTPS nicht wirklich sicher ist haben wir in letzter zeit ja oft genug mitbekommen weil entweder der server oder der client (oder beide) überredet werden kann, auf leicht entschlüsselbare verschlüsselung "runterzuschalten").

    am meisten sorgen würde mir das caching machen.
    auf jeden fall müsste man den daten im cache eine bestimmte lebenszeit geben.
    also dass man zb mindestens alle 48h mal einen synch machen muss (dass zb keine verträge mit kunden abgeschlossen werden welche nicht zahlen, oder deren angebots-modalitäten sich geändert haben etc.

    die caches würde ich dann vom backup ausschließen und nicht via iTunes zugänglich machen (das sind dann aber schon details von denen man jede menge zu beachten hat - und am besten keines davon vergisst).

  • gritsch schrieb:

    das wort "lokal" war wohl etwas ungeschickt gewählt. der server sollte halt im gleichen netz stehen wie der DB-server (eventuell ist es sogar der gleiche server).Aber was würdest du anstelle VPN verwenden? etwa einfach nur HTTPS für jeden nach ausen hin öffnen sodass jedes script-kiddie mal darauf angriffe starten kann (dass HTTPS nicht wirklich sicher ist haben wir in letzter zeit ja oft genug mitbekommen weil entweder der server oder der client (oder beide) überredet werden kann, auf leicht entschlüsselbare verschlüsselung "runterzuschalten").
    das wort "lokal" war wohl etwas ungeschickt gewählt. der server sollte halt im gleichen netz stehen wie der DB-server (eventuell ist es sogar der gleiche server).Aber was würdest du anstelle VPN verwenden? etwa einfach nur HTTPS für jeden nach ausen hin öffnen sodass jedes script-kiddie mal darauf angriffe starten kann (dass HTTPS nicht wirklich sicher ist haben wir in letzter zeit ja oft genug mitbekommen weil entweder der server oder der client (oder beide) überredet werden kann, auf leicht entschlüsselbare verschlüsselung "runterzuschalten").

    am meisten sorgen würde mir das caching machen.
    auf jeden fall müsste man den daten im cache eine bestimmte lebenszeit geben.
    also dass man zb mindestens alle 48h mal einen synch machen muss (dass zb keine verträge mit kunden abgeschlossen werden welche nicht zahlen, oder deren angebots-modalitäten sich geändert haben etc.

    die caches würde ich dann vom backup ausschließen und nicht via iTunes zugänglich machen (das sind dann aber schon details von denen man jede menge zu beachten hat - und am besten keines davon vergisst).
    Warum hält der liebe @kmr denn Vortrag über Vortrag auf der Macoun, wie man sich diesem Thema methodisch nähert, und Ihr werft hier mit Maßnahmen rum, ohne Euch strukturierte Gedanken über das konkrete Bedrohungsszenario gemacht zu haben? Meeeh!


    gritsch schrieb:

    der server sollte halt im gleichen netz stehen wie der DB-server

    Eine suuuuuuuuper Empfehlung! *facepalm*

    gritsch schrieb:

    dass HTTPS nicht wirklich sicher ist haben wir in letzter zeit ja oft genug mitbekommen

    VPN ist technisch betrachtet nicht sicherer als HTTPS. Nur komplexer. Und Komplexität tötet. In Entwicklung und Betrieb. Überdies lassen sich gegen die von Dir beschriebenen Bedrohungen Maßnahmen treffen.

  • kmr schrieb:



    gritsch schrieb:

    der server sollte halt im gleichen netz stehen wie der DB-server
    Eine suuuuuuuuper Empfehlung! *facepalm*
    warum sollte man zugriff auf kritische daten auf verschiedene netze aufteilen? damit man die angriffsfläche verdoppelt? ich kann also netz A (die DB) angreifen, wenn das nicht klappt dann kann ichs ja noch mit netz B versuchen in dem der webservice steht...

  • gritsch schrieb:


    warum sollte man zugriff auf kritische daten auf verschiedene netze aufteilen? damit man die angriffsfläche verdoppelt? ich kann also netz A (die DB) angreifen, wenn das nicht klappt dann kann ichs ja noch mit netz B versuchen in dem der webservice steht...
    Das Prinzip nennt sich Defense in depth, und die Segmentierung von Netzwerken ist eine der elementarsten Maßnahmen der IT-Sicherheit in Infrastrukturen. Wie willst Du denn eigentlich das Netz der DB angreifen, wenn Du nur Zugriff auf den Webservice hast?

  • kmr schrieb:

    gritsch schrieb:

    warum sollte man zugriff auf kritische daten auf verschiedene netze aufteilen? damit man die angriffsfläche verdoppelt? ich kann also netz A (die DB) angreifen, wenn das nicht klappt dann kann ichs ja noch mit netz B versuchen in dem der webservice steht...
    Das Prinzip nennt sich Defense in depth, und die Segmentierung von Netzwerken ist eine der elementarsten Maßnahmen der IT-Sicherheit in Infrastrukturen. Wie willst Du denn eigentlich das Netz der DB angreifen, wenn Du nur Zugriff auf den Webservice hast?
    warum soll ich das netz der DB angreifen wenn ich das netz des webservice angreifen kann? und wenn ich das geschafft habe, kann ich von dort aus auch das netz des DB angreifen.

    ein gut geschütztes netzwerk ist immer noch besser als zwei schlecht geschützte!

  • gritsch schrieb:

    warum soll ich das netz der DB angreifen wenn ich das netz des webservice angreifen kann?
    s.u.

    gritsch schrieb:

    und wenn ich das geschafft habe, kann ich von dort aus auch das netz des DB angreifen.
    ein gut geschütztes netzwerk ist immer noch besser als zwei schlecht geschützte!
    Zum einen steht nirgendwo etwas von "zwei schlecht geschützten" Netzwerken, zum anderen ist diese Aussage in ihrer Pauschalität kompletter Unsinn. Wie immer im Forum gilt auch hier: erst Grundlagen aneignen, dann Diskussion eröffnen. ;)

  • Agenor schrieb:

    Die App muss Unterwegs offline laufen
    dann passt das hier sehr gut:

    NSObject schrieb:

    Bei dem Setup würde sich CouchDb und TouchDB/Couchbase anbieten.

    Lektüre:
    TouchDB iOS - 8. Replication
    Mobiler Einsatz von CouchDB - Macoun 2013

    über den ganzen quatsch von wegen Sicherheit im Internet brauchst dir keine Gedanken machen, wenn man den sync Vorgang nur im eigenen WLAN vor Ort zulässt bzw. über das Netzwerk über VPN.

    Zur Sicherheit:
    Wenn es VPN bereits gibt, spielt es auch keine Rolle, ob es potentiell unsicher sein könnte wenn du eine App darüber kommunizieren lässt, da die Daten dort eh schon bereit liegen für einen eventuellen Eindringling und die App auf diesen Zustand eh keinen Einfluss haben wird. Du schreibst ja auch keinen VPN Client, sondern kommunizierst nur über ein vorhandenes Netzwerk, welches in diesem Fall VPN ist.