2015-05-27 17 views
5

Używam uwierzytelnionego mechanizmu opartego na tokenach na moim serwerze. Gdy użytkownik loguje się przez aplikację na Androida, serwer zwraca token, który należy wysłać przy każdym kolejnym żądaniu. Muszę zapisać tę wartość na urządzeniach. Ponieważ token jest prostym łańcuchem, pomyślałem, że będę używał wartości SharedPreferences. Gdy aplikacja zaczyna się wewnątrz MyApplication extends Application, pytam o ten token za SharedPreferences i trzymam go wewnątrz MyApplication jako stan globalny, aby każde działanie mogło uzyskać do niego dostęp, gdy wysyła żądanie do serwera.Użyj `SharedPreferences` do przechowywania tokena uwierzytelniania

Czy to podejście jest wykonalne? Jeśli nie, jakie to ma istotne wady? A jeśli to zły pomysł, jakie jest alternatywne podejście?

PS. To nie jest subiektywne pytanie - nie pytam o podejście the best, potwierdzam moje założenia.

+1

Czy zastanawiasz się nad używaniem konta AccountManager? z setAuthToken i getAuthToken? – ataulm

+0

Nie, dziękuję za podpowiedź. Na pierwszy rzut oka wydaje się trudniejsze do zrealizowania niż utrzymywanie tokena w "SharedPreferences". Ale mogę wziąć to pod uwagę w przyszłości –

+0

tak, zdecydowanie jest to ból głowy. Po prostu jest to "właściwe" podejście. – ataulm

Odpowiedz

4

Jest dość bezpieczny. Użytkownicy nie będą mieli dostępu do SharedPreferences, chyba że mają zrootowane urządzenia. Jeśli obawiasz się o bezpieczeństwo tak bardzo, możesz zaszyfrować token przed zapisaniem go w numerze SharedPreferences.

2

Jest to ważna opcja, jeśli nie chcesz używać pliku database lub napisać tokena w pliku. Brak wady, którą mogę sobie wyobrazić, to:

1

Ma jeden błąd, jeśli urządzenie jest zrootowane. Użytkownik może zobaczyć token z SharedPreferences na swoim urządzeniu, jeśli urządzenie jest zrootowane. Proponuję przechowywać dane w bazie danych/SQLite za pomocą Sugar here dla lepszego podejścia do serwera.

Powiązane problemy