Offline Login-System (PWA)

  • Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
Hey,

wie der Titel schon sagt, will ich ein Offline Login-System in eine PWA einbauen.
Meine Frage ist nicht wie ich die Daten offline speichere, sondern wo?
Wo speichert man solche Daten, mit welcher Methode?

Danke für jeden der hilft.

Grüße
Aaron
 

Tronjer

Senior HTML'ler
8 Oktober 2010
5.238
483
83
Berlin
Normaler Weise im Service Worker Cache. Das funktioniert aber mit POST-Requests nicht. Allerdings gibt es Workarounds dafür. Einfach mal googeln.
 
  • Like
Reaktionen: Aaron3219

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
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:

Das funktioniert aber mit POST-Requests nicht.
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
14 Juli 2011
2.552
448
83
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:


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.

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.
 

Tronjer

Senior HTML'ler
8 Oktober 2010
5.238
483
83
Berlin
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.
 

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
Auf keinen Fall :D. 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
14 Juli 2011
2.552
448
83
Auf keinen Fall :D. 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).

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.
 
  • Like
Reaktionen: Aaron3219

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
Passt. Nehme den Weg, wo ich ausschließlich Requests im Service-Worker Cache speichere.
 

Tronjer

Senior HTML'ler
8 Oktober 2010
5.238
483
83
Berlin
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.
 

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
Aber wie eingangs erwähnt eben keine POST-Requests.
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:
An interesting solution is the one presented in the ServiceWorker Cookbook: https://serviceworke.rs/request-deferrer.html Basically, the solution serializes requests to IndexedDB.
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:

Tronjer

Senior HTML'ler
8 Oktober 2010
5.238
483
83
Berlin
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?
 

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
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.
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
14 Juli 2011
2.552
448
83
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?

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".
 

Aaron3219

Senior HTML'ler
6 Oktober 2015
1.148
237
63
19
Achso. Ja das ist mir bewusst.

Jetzt muss ich erstmal herausfinden, wie man mit Laravel wohl eine PWA baut...
 
Zuletzt bearbeitet:
Werbung: