Offline Login-System (PWA)
- Ersteller Aaron3219
- Erstellt am
-
- Schlagworte
- login login-system offline offline login-system php pwa
Aaron3219
Senior HTML'ler
Der Service Woker Cache kann doch von jedem eingesehen werden. Dann könnte man ja theoretisch einfach Hashes mit Rainbow-Tables abgleichen.
Was passiert außerdem, wenn man z.B. 10.000 Nutzer hat? Funktioniert es mit so großen Datensätzen? Die müssten dann ja alle in JSON-Arrays oder ähnlichem gespeichert werden.
Edit:
Ich weiß, dass GET-Requests zwar von einigen Browsern (wie IE) gecached werden, was dazu führen kann,
dass man immer den gleichen Wert (Trotz Serverside-Änderung) bekommt, die PWA wird aber eh nur
im Android Web-View verwendet, der meines Wissens nach GET-Requests nicht cached.
Edit 2:
Könnte man nicht auch Offline-DBs wie PouchDB benutzen? Die benutzen die IndexedDB und kannst da POST-Requests machen.
Was passiert außerdem, wenn man z.B. 10.000 Nutzer hat? Funktioniert es mit so großen Datensätzen? Die müssten dann ja alle in JSON-Arrays oder ähnlichem gespeichert werden.
Edit:
GET-Requests sollten doch auch funktionieren, solange man HTTPS-Protokolle benutzt.
Ich weiß, dass GET-Requests zwar von einigen Browsern (wie IE) gecached werden, was dazu führen kann,
dass man immer den gleichen Wert (Trotz Serverside-Änderung) bekommt, die PWA wird aber eh nur
im Android Web-View verwendet, der meines Wissens nach GET-Requests nicht cached.
Edit 2:
Könnte man nicht auch Offline-DBs wie PouchDB benutzen? Die benutzen die IndexedDB und kannst da POST-Requests machen.
Zuletzt bearbeitet:
scbawik
Senior HTML'ler
Was hast du denn überhaupt vor? Also was willst du bezwecken?
Du kannst die Benutzertabelle nicht herunterladen und dich dann lokal anmelden.
Du musst dich immer online authentifizieren.
Vielleicht habe ich das falsch verstanden, aber du willst nicht ernsthaft eine komplette Datenbank auf den Rechner des Users herunterladen, damit dieser sich dort einloggen kann? Das wäre die dümmste Lösung ever.
Mein Ansatz bezog sich darauf, wie man ausgehende Requests cached, falls der User zeitweilig offline ist. Weil er z.B. in der U-Bahn sitzt und dort keinen Empfang hat. Und um IndexedDB zu nutzen, braucht es keine weitere Datenbank.
Mein Ansatz bezog sich darauf, wie man ausgehende Requests cached, falls der User zeitweilig offline ist. Weil er z.B. in der U-Bahn sitzt und dort keinen Empfang hat. Und um IndexedDB zu nutzen, braucht es keine weitere Datenbank.
Aaron3219
Senior HTML'ler
Auf keinen Fall 
. Eine komplette User-Tabelle herunterzuladen ist keine so gute Idee.
Die Sache ist ein wenig komplexer und eventuell sicherer als ihr gerade glaubt.
Ich glaube eure Bedenken sind, dass jeder User die Daten aller User erhält. Dem ist aber nicht so.
Alle User sind einer Gruppe zugeordnet, die, für mein Beispiel, z.B. eine Firma oder vergleichbares darstellt (Tenant).
Dann gibt es da noch die Geräte. Jedes neue Gerät muss vom Tenant freigeschaltet werden. Ohne diese Freischaltung, passiert da gar nichts.
Das Gerät wird dann genau einem Tenant zugewiesen. Ist dies passiert, DANN werden die Daten für die User heruntergeladen, aber NUR für DIESEN Tenant.
Dabei handelt es sich um maximal 50 Nutzer.
Sprich: Auf einem Gerät sind nur die User-Daten für die User des Tenants (also z.B. einer Firma).
Die Geräte bleiben Tenant-intern und sind für niemanden außer die User des Tenants zugänglich.
Es ist also nicht möglich, dass fremde an die User-Daten kommen und auch andere Tenants nicht.
Des Weiteren kommt hinzu, dass die PWA ausschließlich im Android WebView benutzt werden kann. Ich recherchiere da gerade noch aber ich glaube, dass du z.B. die IndexedDB im Android WebView nicht einfach so verändern oder überhaupt eingesehen werden kann. Die Daten werden natürlich encrypted.
Damit also irgendwas schief gehen kann, müsste ein User des Tenants an ein zugewiesenes Gerät (immer ein Smartphone) des Tenants kommen und (falls möglich) die IndexedDB vom Android WebView auslesen und die Daten entschlüsseln (sofern er sie nicht verändern kann).
Das WAR der Plan. Da mir aber von Anfang an schon bewusst war, dass es da deutlich bessere Methoden gibt, habe ich mittlerweile ein System, dass ausschließlich Online Authentifiziert. Um das kurz zu erklären:
Die PWA behandelt die Statusrückmeldung von irgendwas. Welchen Status, der Name des Status, usw. ist natürlich Tenant-spezifisch und kann von jedem Tenant bestimmt werden. Dazu muss wie im anderen Ansatz immer noch das Gerät freigeschaltet werden. Um die App auch offline benutzen zu können wird (sofern die App offline gestartet wird) erstmal KEINE Authentifizierung abgefragt. Die Konfigurationen für die verschiedenen Status werden aber heruntergeladen. Man führt also Offline eine Statusrückmeldung durch, die erstmal lokal gespeichert wird. Ist man wieder Online, wird der Status erst synchronisiert, wenn dann eine Online-Authentifizierung erfolgt ist.
Variante 1 ist unsicherer, aber so würde ich es gerne machen, wenn es nicht zu unsicher ist (da warte ich auf eure Rückmeldung).
Variante 2 ist deutlich sicherer (glaube ich zumindest, auch da warte ich auf eure Rückmeldung).
. Eine komplette User-Tabelle herunterzuladen ist keine so gute Idee.Die Sache ist ein wenig komplexer und eventuell sicherer als ihr gerade glaubt.
Ich glaube eure Bedenken sind, dass jeder User die Daten aller User erhält. Dem ist aber nicht so.
Alle User sind einer Gruppe zugeordnet, die, für mein Beispiel, z.B. eine Firma oder vergleichbares darstellt (Tenant).
Dann gibt es da noch die Geräte. Jedes neue Gerät muss vom Tenant freigeschaltet werden. Ohne diese Freischaltung, passiert da gar nichts.
Das Gerät wird dann genau einem Tenant zugewiesen. Ist dies passiert, DANN werden die Daten für die User heruntergeladen, aber NUR für DIESEN Tenant.
Dabei handelt es sich um maximal 50 Nutzer.
Sprich: Auf einem Gerät sind nur die User-Daten für die User des Tenants (also z.B. einer Firma).
Die Geräte bleiben Tenant-intern und sind für niemanden außer die User des Tenants zugänglich.
Es ist also nicht möglich, dass fremde an die User-Daten kommen und auch andere Tenants nicht.
Des Weiteren kommt hinzu, dass die PWA ausschließlich im Android WebView benutzt werden kann. Ich recherchiere da gerade noch aber ich glaube, dass du z.B. die IndexedDB im Android WebView nicht einfach so verändern oder überhaupt eingesehen werden kann. Die Daten werden natürlich encrypted.
Damit also irgendwas schief gehen kann, müsste ein User des Tenants an ein zugewiesenes Gerät (immer ein Smartphone) des Tenants kommen und (falls möglich) die IndexedDB vom Android WebView auslesen und die Daten entschlüsseln (sofern er sie nicht verändern kann).
Das WAR der Plan. Da mir aber von Anfang an schon bewusst war, dass es da deutlich bessere Methoden gibt, habe ich mittlerweile ein System, dass ausschließlich Online Authentifiziert. Um das kurz zu erklären:
Die PWA behandelt die Statusrückmeldung von irgendwas. Welchen Status, der Name des Status, usw. ist natürlich Tenant-spezifisch und kann von jedem Tenant bestimmt werden. Dazu muss wie im anderen Ansatz immer noch das Gerät freigeschaltet werden. Um die App auch offline benutzen zu können wird (sofern die App offline gestartet wird) erstmal KEINE Authentifizierung abgefragt. Die Konfigurationen für die verschiedenen Status werden aber heruntergeladen. Man führt also Offline eine Statusrückmeldung durch, die erstmal lokal gespeichert wird. Ist man wieder Online, wird der Status erst synchronisiert, wenn dann eine Online-Authentifizierung erfolgt ist.
Variante 1 ist unsicherer, aber so würde ich es gerne machen, wenn es nicht zu unsicher ist (da warte ich auf eure Rückmeldung).
Variante 2 ist deutlich sicherer (glaube ich zumindest, auch da warte ich auf eure Rückmeldung).
Zuletzt bearbeitet:
scbawik
Senior HTML'ler
Auf keinen Fall
Die Sache ist ein wenig komplexer und eventuell sicherer als ihr gerade glaubt.
Ich glaube eure Bedenken sind, dass jeder User die Daten aller User erhält. Dem ist aber nicht so.
Alle User sind einer Gruppe zugeordnet, die, für mein Beispiel, z.B. eine Firma oder vergleichbares darstellt (Tenant).
Dann gibt es da noch die Geräte. Jedes neue Gerät muss vom Tenant freigeschaltet werden. Ohne diese Freischaltung, passiert da gar nichts.
Das Gerät wird dann genau einem Tenant zugewiesen. Ist dies passiert, DANN werden die Daten für die User heruntergeladen, aber NUR für DIESEN Tenant.
Dabei handelt es sich um maximal 50 Nutzer.
Sprich: Auf einem Gerät sind nur die User-Daten für die User des Tenants (also z.B. einer Firma).
Die Geräte bleiben Tenant-intern und sind für niemanden außer die User des Tenants zugänglich.
Es ist also nicht möglich, dass fremde an die User-Daten kommen und auch andere Tenants nicht.
Des Weiteren kommt hinzu, dass die PWA ausschließlich im Android WebView benutzt werden kann. Ich recherchiere da gerade noch aber ich glaube, dass du z.B. die IndexedDB im Android WebView nicht einfach so verändern oder überhaupt eingesehen werden kann. Die Daten werden natürlich encrypted.
Damit also irgendwas schief gehen kann, müsste ein User des Tenants an ein zugewiesenes Gerät (immer ein Smartphone) des Tenants kommen und (falls möglich) die IndexedDB vom Android WebView auslesen und die Daten entschlüsseln (sofern er sie nicht verändern kann).
Das WAR der Plan. Da mir aber von Anfang an schon bewusst war, dass es da deutlich bessere Methoden gibt, habe ich mittlerweile ein System, dass ausschließlich Online Authentifiziert. Um das kurz zu erklären:
Die PWA behandelt die Statusrückmeldung von irgendwas. Welchen Status, der Name des Status, usw. ist natürlich Tenant-spezifisch und kann von jedem Tenant bestimmt werden. Dazu muss wie im anderen Ansatz immer noch das Gerät freigeschaltet werden. Um die App auch offline benutzen zu können wird (sofern die App offline gestartet wird) erstmal KEINE Authentifizierung abgefragt. Die Konfigurationen für die verschiedenen Status werden aber heruntergeladen. Man führt also Offline eine Statusrückmeldung durch, die erstmal lokal gespeichert wird. Ist man wieder Online, wird der Status erst synchronisiert, wenn dann eine Online-Authentifizierung erfolgt ist.
Variante 1 ist unsicherer, aber so würde ich es gerne machen, wenn es nicht zu unsicher ist (da warte ich auf eure Rückmeldung).
Variante 2 ist deutlich sicherer (glaube ich zumindest, auch da warte ich auf eure Rückmeldung).
Um zuerst einmal eines klarzustellen: IndexedDB ist komplett OP für nahezu alle Aufgaben.
Es gibt kaum einen Grund das einzusetzen, abseits von hochkomplexen Mega-Anwendungen.
Die Remote Datenbank in eine IndexedDB synchronisieren zu wollen, ist auch ein vollkommen falscher Ansatz.
Die Nutzer fragst du ganz normal von der API ab und cached diese Response dann im Service Worker.
Wenn der Nutzer offline ist, kannst du auf die Response im Cache zugreifen.
IndexedD ergibt dann Sinn, wenn im Browser anstatt einfacher Key-Value-Pairs Arrays von Objekten persistiert werden sollen. Zwar lassen sich Arrays auch stringified in den LocalStorage schreiben und beim Auslesen per Schleife durchsuchen, aber ein Query auf die IndexedDB ist die elegantere Lösung.
Aber wie eingangs erwähnt eben keine POST-Requests.
Aaron3219
Senior HTML'ler
Ist richtig. Und das ist auch eigentlich kein Problem. Man sollte aber ja eigentlich keine GET-Requests machen, wenn es um sensitive data geht, was bei dem Abfragen des Users aber zum Problem wird... Macht da https die Sache sicher?
Edit:
https://stackoverflow.com/questions/35270702/can-service-workers-cache-post-requests
Also auf Stackoverflow wurde das Thema kurz angesprochen. Die sagen:
Der Link funktioniert leider nicht mehr... Aber "Basically, the solution serializes requests to IndexedDB." liefer ja im Prinzip einen Lösungsansatz, der zumindest in meinen Augen plausibel klingt.
Zuletzt bearbeitet:
Ein SSL-Zertifikat sollte ohnehin Pflicht sein, wenn sensible Daten übertragen werden.
Aber genau genommen kannst du es dir doch einfacher machen. Du sendest einen POST-Request und wenn der fehlschlägt, werden die Daten im LocalStorage gespeichert und nach einer bestimmten Zeit erneut abgeschickt. Wozu benötigst du da einen ServiceWorker, der in einem Background-Thread läuft?
Aber genau genommen kannst du es dir doch einfacher machen. Du sendest einen POST-Request und wenn der fehlschlägt, werden die Daten im LocalStorage gespeichert und nach einer bestimmten Zeit erneut abgeschickt. Wozu benötigst du da einen ServiceWorker, der in einem Background-Thread läuft?
Aaron3219
Senior HTML'ler
Das verstehe ich noch nicht ganz... Also ich sende Online einen POST-Request, der nicht gecached wird. Sobald ich offline bin, schlägt der POST-Request fehl und ich speichere die Daten im LocalStorage. Aber was soll ich denn da speichern? Wenn ich vorher nichts cache, dann kann ich ja auch nichts speichern oder verstehe ich da was falsch?
scbawik
Senior HTML'ler
Du speicherst das JSON, das du versenden willst im LocalStorage und versuchst es einfach fortlaufend neu abzuschicken bis es funktioniert. Mit "cachen" hat das gar nichts zu tun. Eher "queuen".