Login merken und activities öffnen - shared preferences

H

haner

Ambitioniertes Mitglied
0
Hallo,
ich möchte meine App so umgestalten, dass für den Aufruf einzelner Activities ein Login erforderlich ist. Momentan habe ich es so programmiert, dass beispielsweise beim Anklicken eines Buttons X in der MainActivity eine LoginActivity geöffnet wird. Dort folgt die Eingabe der Login-Daten (Benutzername und Passwort). Nach einem erfolgreichen Abgleich mit den in einer mysql-Datenbank gespeicherten Userdaten wird die Activity Y geöffnet.
Was muss ich tun, um die Logindaten zu "speichern"? D. h. ich möchte mich in der LoginActivity anmelden. Anschließend sollen die Daten bis zu einem späteren Anklicken eines Logout-Buttons gespeichert bleiben. Zwischenzeitlich soll es dem User ermöglicht werden, sämtliche Activities (die nur bei erfolgreichem Login zu öffnen sind) aufzurufen, ohne jedesmal seine Userdaten neu eingeben zu müssen.

Wie geht man bei so etwas am besten vor? Nach welchen Stichworten muss ich hierzu im Web suchen? Bin bereits auf "shared preferences" gestoßen. Ist das das Schlüsselwort. Ich kann mir denken, dass mein beschriebenes Problem schon mehrfach behandelt worden ist, werde aber nicht konkret fündig. Kennt jemand evtl. ein Tutorial oder ähnliches, das meine Problematik behandelt?

VG
 
Ich würde es nicht in SharedPreferences speichern, denn dann ist das Passwort auch noch da wenn die App vom System oder User geschlossen wird.
Manche halten es vielleicht für ein Antipattern, aber ich würde hierfür ein Singleton empfehlen, in dem du die Daten ablegst. (brauchst du immer Login und Passwort in den geschützten Activities oder reicht dir vielleicht ein "loggedin = true" flag?)
Dieses Singleton kannst du dann in jeder geschützten Activity anfragen und wenn der User eingeloggt ist machst du nichts, ist er nicht eingeloggt leitest du ihn zum Login weiter. Der Login schreibt dann die benötigten Daten in das Singleton nach dem erfolgreichen einloggen und leitet wieder zurück zur Ursprungsactivity.

Ich selbst habe es hier schonmal gemacht: masterpassword/MasterPasswordHolder.java at master · dkunzler/masterpassword · GitHub
In der Klasse speichere ich einen MasterKey zur Verwendung in verschiedenen anderen Klassen.
Ich benutze hier das enum Singleton pattern, du kannst aber auch reguläres double-checked locking, singletonHolder oder ein Singleton Pattern deiner Wahl verwenden ;)
 
  • Danke
Reaktionen: haner, swa00 und lordzwieback
zunächst einmal danke für deine Informationen.
deek schrieb:
Ich würde es nicht in SharedPreferences speichern, denn dann ist das Passwort auch noch da wenn die App vom System oder User geschlossen wird.
Genau das möchte ich so haben! Man soll nicht jedes mal, wenn die App neu geöffnet wird das Passwort neu eingeben müssen. Heißt das, ich muss dann doch SharedPreferences verwenden? Bzw. welche Nachteile hat SharedPreferences?
 
Heißt das, ich muss dann doch SharedPreferences verwenden? Bzw. welche Nachteile hat SharedPreferences?

a) Muss ? Nein , du kannst auch mit einer SQlite DB arbeiten
b) Jeder kann halt, wenn er mag - die Daten im Klartext einsehen - das ist halt nicht sicher, es sei denn du machst noch eine Verschlüsselung drauf
 
swa00 schrieb:
Jeder kann halt, wenn er mag - die Daten im Klartext einsehen

Kannst du mir bitte das "jeder" konkretisieren. Wer ist damit gemeint? Jeder der Zugang zum Smartphone mit dieser App hat, in der aktuell jemand eingelogged ist?
 
a) warum einen Login basteln, wenn er nur einmal einzugeben ist und jedesmal , wenn die app erneut gestartet wird , keinen login mehr
benutzen (da gesichert) - Macht irgendwie nicht so recht einen sinn ... aber das ist deine Entscheidung
b) die Shares können von jeder x-beliebigen anderen App auch eingesehen werden - wenn das dir egal ist und der login nicht sensibel, dann kannst du das so lassen

Share = Sharing = Teilen
 
swa00 schrieb:
die Shares können von jeder x-beliebigen anderen App auch eingesehen werden - wenn das dir egal ist und der login nicht sensibel, dann kannst du das so lassen
Egal ist mir das natürlich nicht. Ich bin momentan nur auf der Suche mein Anliegen möglichst sicher und als absoluter Android-Neuling möglichst einfach umzusetzen zu können. Um nochmal auf dein Stichwort sq-lite DB zurückzugreifen: Kannst du mir hierzu noch ein paar Schlüsselwörter "zuwerfen", nach denen ich in diesem Zs.hang googeln kann, um mich näher hierzu informieren zu können. Stoße bei meiner Recherche momentan fast ausschließlich auf Tutorials mit SharedPreferences und dachte, dass das dann wohl die beste Lösung sein wird. Da das nun aber nicht sicher genug scheint, muss ich wohl eine andere Richtung einschlagen.
 
Nichts einfacher als das... erster Treffer bei Tante Google :)

Android SQLite Database Tutorial

Viel Erfolg

P.S aber auch hier das Verschlüsseln nicht vergessen
 
  • Danke
Reaktionen: deek
Naja, so ist das ja auch nicht, die SharedPreferences liegen in deinem geschützten AppData Verzeichnis. Wenn du die Preferences nicht als WORLD_READABLE markierst kommt ohne root erstmal keiner ran.
Ich stimme aber zu, dass es wenig Sinn macht ein Passwort anzufordern und das danach für immer zu speichern.

Und um das PW zu speichern sind SharedPreferences deutlich einfacher als eine Datenbank. (und auch deutlich geeigneter)
 
  • Danke
Reaktionen: swa00
deek schrieb:
Ich stimme aber zu, dass es wenig Sinn macht ein Passwort anzufordern und das danach für immer zu speichern.
Warum macht das keinen Sinn? Das machen doch alle bekannten Apps (Facebook und co.) so! Ich finde es gut nicht bei jedem Neustart einer App das Passwort neu eingeben zu müssen. Etwas übertrieben gesagt, wäre man da ja meist länger mit Passwort eingeben beschäftigt, als dass man die App verwendet, um das zu machen, was man damit eigentlich erledigen möchte.
 
@deek , übernimm du bitte :)
 
...mal ein ganz blauäugiger Vorschlag:

Du kannst eine Art Token erstellen, den kannst du in einer Projekt-Internen Datei speichern. Es ist nicht nötigt das Passwort im Klartext zu senden oder zu speichern.
Speichere in der Datenbank nur den Hashwert zu dem Passwort. Auch nur dieser Hashwert wird bei der Passwort abfrage geprüft.

In der Datei im Internal Storage (Saving Files | Android Developers) brauchst du dann nur ablegen, dass der User aktuell erfolgreich eingeloggt ist und eventuell noch eine Gültigkeitsdauer / -ende oder Datum etc.
 
a) Facebook und Konsorten verwenden das Passwort um dich gegen den Server zu identifizieren. Wenn ich dich richtig verstehe willst du die Activities nur lokal "locken" ohne Server Interakton.
b) Facebook und Konsorten speichern nicht das Passwort sondern bekommen nach dem Login am Server einen zufällig generierten String (Token) der mit deinem User und deiner Session verknüpft ist. Bei weiteren Anfragen wird nur das Token verwendet und Facebook kann das dann zuordnen. Das Passwort ist also nicht gespeichert und kann nicht so einfach vom Gerät geklaut werden.

Wenn du ebenfall einen Login auf einem Server machst sieht die Sache ob es sinnvoll ist wieder anders aus, aber dann solltest du dir über Session Management Gedanken machen, statt das PW im Klartext zu speichern und immer mitzuschicken.
[doublepost=1517411364,1517411268][/doublepost]Beispiele für eine lokale Version von einem Passwort sind z.B. Banking Apps. Hier muss ich auch ein Passwort eingeben um die App verwenden zu können. Dieses wird nur lokal verwendet um Inhalt freizugeben oder zu entschlüsseln, aber im Regelfall nicht zum Server geschickt. Hier muss man sich dann entweder bei jedem Start oder halt nach einem festgelegten Timeout neu authenfizieren.
 
Meine App ist so aufgebaut, dass es einzelne Activities gibt, in denen in editText-Felder eingegebene Daten in eine mysql-DB hochgeldaen werden. Auf diese Activities sollen nur eingeloggte User Zugriff haben, damit nicht jeder etwas in die DB hochladen kann. Dazu würde ich nun mal vorsichtig behaupten, dass ich keinen Login auf einem Server benötige. Trotzdem möchte ich mich aber nicht nach jedem App-Neustart und nach einem Time-Out neu einloggen müssen.
 
Du übermittelt die Daten zu deiner Datenbank via Http? Du solltest dir doch ein System zur Absicherung der Datenbank überlegen.
Man kann sonst auch ohne deine App Daten in die Datenbank schieben.
Was läuft denn sonst auf deinem Server neben der Datenbank? Kannst du bei deiner Datenbank externen Zugriff erlauben?
Läuft Php, Django, Ruby on Raus, NodeJS oder etwas ähnliches auf dem Server?
 
  • Danke
Reaktionen: deek
keen schrieb:
Du übermittelt die Daten zu deiner Datenbank via Http?
Ja.

keen schrieb:
Was läuft denn sonst auf deinem Server neben der Datenbank? Kannst du bei deiner Datenbank externen Zugriff erlauben?
Läuft Php, Django, Ruby on Raus, NodeJS oder etwas ähnliches auf dem Server?
php läuft auf dem Server.
 
Hallo,

das sicherste wäre natürlich https, kostet aber leider auch. Wenn du vor hast die App zu veröffentlichen im App Store dann solltest du es verschlüsselt machen.

Wenn es nur ein privates Projekt ist, dann kannst du auch AES nutzen.
Daten verschlüsselt übertragen zum Webspace
 
Bei Php und Mysql gibt es einiges zu beachten. Stichwort 'SQLInjection'.
Die Verbindung zum Webserver sollte verschlüsselt ausgeführt werden.
Man kann den Treffen einer App ganz einfach per Proxy oder sogar WireShark mit schneiden und kopieren oder manipulieren. Daher solltest du deinen Webserver schon ganz gut absichern. Vorausgesetzt , du willst die App nicht nur im kleinsten Kreis nutzen. Aber auch dann sollte wenigstens eine Grundabsicherung vorhanden sein.

Vielleicht hilft dir ja Amazon AWS oder Google App Engine bei der Erstellung der App. Dann kommst du vielleicht ohne eigenes Php und SQL aus.
 
  • Danke
Reaktionen: haner
Besten Dank für eure zahlreichen Ratschläge und Hinweise. Ja, die App soll später in den PlayStore. Bis dahin werde ich sie aber erstmal im kleinen Kreis testen. Der aktuelle Plan ist nun das Abfragen des Login-Status über das Anlegen einer Datei im internen Storage. Dort speichere ich bei erfolgreichem Login ein "yes". Solange ein "yes" gespeichert ist, kann dann auf die Activities mit notwendigem Login zugegriffen werden.
 
Zuletzt bearbeitet:

Ähnliche Themen

F
Antworten
0
Aufrufe
809
FlorianAlfredo
F
B
Antworten
6
Aufrufe
1.002
jogimuc
J
D
Antworten
9
Aufrufe
1.721
jogimuc
J
Zurück
Oben Unten