Datenbankhandling über eine Cloud?

[Rollo62]

Vielleihct ist "mandantenfähig" zu viel des Guten.

Was ich meine ist, du hast ein App,

1. wo sich sagen wir mal 1000-10000 einzelne Nutzer registrieren.
2. jeder User kann sich selbst registrieren und bekommt ein Unique-UserToken.
3. Jetzt möchte jeder vielleicht seinen kleinen Bereich nutzen,
   sei es seine Settings speichern, seine Messdaten speichern, nichts Besonderes halt.

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?

Wenn ich dafür schon die "mandantenfähige" Cloud brauche bin ich schnell im 3-4 stelligen Bereich pro Monat, und deshalb halte ich noch ziemlichen Abstand zur Cloud.
Und der User müsste aufwändig an der Cloud registriert werden.
Das mit der "günstigen" Cloud ist IMHO nämlich eine Mogelpackung

Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt )

Über DropBox, OwnCloud, etc. habe ich natürlich entsprechend auch nachgedacht,
ich bin aber im Moment eher bei einer kleinen PHP-Lösung mit REST-Service stehengeblieben.

Rollo

[Morphie]

Zitat von Rollo62:

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?
...
Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt )

Ich habe deine Bedenken noch nicht so ganz verstanden.
Normalerweise läuft es doch so, dass man irgendeine REST-API (oder ähnliches) in der Cloud hostet, an die man sich dann technisch per Access-Token anmeldet. (OAuth2)
Zu keiner Zeit hat ein Nutzer von außerhalb direkten Zugriff auf die Datenbank. Jede Anfrage muss also durch die API gestellt werden, die natürlich nur die Daten bereitstellt, die für den angemeldeten Benutzer (über den Access-Token) ersichtlich sein sollen.

[Rollo62]

Was ich meine ist:

Wenn eine App und deren Cloud die Nutzerverwaltung selber macht,
dann gibt es EINEN AppToken, mit dem ich theoretisch auf alle Bereiche zugreifen kann.

Wenn die App also Nutzer anlegen, löschen, etc. kann, dann könnte sie auch auf ALLE Nutzerdatentabellen zugreifen.

Der Zugriff müsste in der Cloud verhindert werden, durch eine Art "UserToken" oder "Mandanten-Steuerung", wie auch immer.
So das ein angemeldeter User nur auf SEINE eigenen Daten zugriff hat.

Die App könnte z.B. sowas einbauen, aber ein Hacker könnte immer an den lokal gespeicherten AppToken kommen und sich generellen Zugriff verschaffen.
Es muss eine Art UserToken geben, den nur die Cloud verwaltet, und die Tabellen und Daten gegeneinander abschottet.


Rollo

[Morphie]

Im Grunde ist es dasselbe Problem wie bei Anmelde-Cookies auf einer Website.
Daher ist sicherzustellen dass die Tokens nicht extern ausgelesen werden können (Dafür gibt es in der Regel spezielle Mechanismen auf den Devices).
Außerdem benötigt man ein sicheres Übertragungsmedium. (HTTPS)

[Rollo62]

Ja, der Web-Server kümmert sich darum.

Aber die einfachen Cloud-Tabellen eben nicht automatisch.
So sehe ich das zumindest.
Entweder muss man das mit anderen Anmelde-Diensten verknüpfen, oder in der Cloud Mehrnutzer-Handling beantragen/zukaufen, etc.

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Es sei denn es gäbe einen Trick das auch bei AWS, Azure, etc. mit einfachen Mitteln hinzubekommen.
Der Tipp mit Firebase geht ja in die Richtung, muss ich checken.

[mjustin]

Zitat von Rollo62:

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Selbst verwalten bringt natürlich wieder den Aufwand der Benutzer- und Passwortverwaltung mit sich. Wenn es um eine App geht, sind Facebook oder Google Konten eine beliebte Methode, ohne weitere Passworteingabe authentifizieren zu können. Damit braucht man auf dem Server keine Benutzer/Passwortzuordnung mehr. Sobald ein Benutzer z.B. ein Google Konto auf dem Smartphone nutzt, kann Google ein kontobezogenes Zugriffstoken erzeugen - dieses kann die App an den Server senden, der Server (z.B. ein Webservice) kann dieses Token bei Google gegenchecken lassen. Falls Google das Token als gültig bestätigt, kann der Server dem Client vertrauen. "Wer" der Client ist, kann der Server aus der Google-Antwort auslesen (z.B. die registrierte E-Mailadresse des Kontos).

p.s. mit der Google App Engine hatte ich vor einigen Jahren eine cloudbasierte Datenbank für Delphi madExcept Bugreports im Betatest[1][2], diese unterstützte bereits OpenID Identitätsprovider und trennte die Benutzerdaten je registriertem Benutzerkonto (aus Zeitmangel habe ich die Entwicklung dann eingestellt).

[1] https://www.delphipraxis.net/159516-...tegration.html
[2] https://mikejustin.wordpress.com/201...-in-the-cloud/

[Rollo62]

Hallo Michael,

ja dankesehr für die Info.
In Richtung BugTracker hatte ich auch schon überlegt, und ein Mantis-System hat z.B. einen SOAP-Zugang.
Ist aber nicht zum Speichern gedacht.

Zitat:

Google ein kontobezogenes Zugriffstoken erzeugen - dieses kann die App an den Server senden, der Server (z.B. ein Webservice) kann dieses Token bei Google gegenchecken lassen.

Das ist die Variante mit dem Mehraufwand, mit separaten z.B. PHP-Server, richtig ?
Oder meinst du das soetwas in den Clouds schon in Simpel existiert ?

Gibt es da von dir irgend etwas Fertiges in diese Richtung, um das einfach einzubinden ?
Das wäre ja interessant.

Mit Facebook-ID hatte ich auch schon geliebäugelt als Authentifizierung,
geht angeblich ohne weitere Services und Kosten.

Rollo