2017-05-13 65 views
6

Mam interfejs API REST Node-Express, w którym mogę wysłać żądanie GET do kontrolera użytkownika - /users/:id - gdzie :id to numer identyfikacyjny użytkownika przechowywany w bazie danych. Mam również aplikację po stronie klienta React-Redux, która wykonuje wywołanie do interfejsu API. Aby spełnić żądanie, aplikacja kliencka musi mieć dostęp do identyfikatora użytkownika, ale obecnie nie jestem pewien, w jaki sposób najlepiej przechowywać identyfikator użytkownika po stronie klienta.Przechowywanie ID użytkownika w aplikacji po stronie klienta dla żądania API

Dla dodatkowego kontekstu, mój interfejs API wysyła do klienta: JWT token przy logowaniu zawierającym identyfikator użytkownika; aplikacja klienta zapisuje token w wersji localStorage. Kiedy klient wysyła żądanie, API sprawdza, czy identyfikator użytkownika w dekodowanym tokenie jest zgodny z identyfikatorem zawartym w adresie URL przed wysłaniem odpowiedzi do klienta.

Widzę dwa możliwe rozwiązania:

  1. Decode tokenu JWT na kliencie i użyć identyfikator użytkownika przechowywane w znak, aby wykonać połączenie API. Myślę, że to potencjalne zagrożenie bezpieczeństwa, ponieważ uważam, że będę musiał przechowywać sekret w aplikacji klienckiej. Każdy, kto ma token, może uzyskać dostęp do informacji o użytkowniku.
  2. Interfejs API wysyła identyfikator użytkownika podczas uwierzytelniania, a klient zapisuje go w numerze localStorage. (Nie sądzę, aby przechowywanie go w sklepie Redux działało, ponieważ użytkownik mógłby odświeżyć, wyczyszczając stan identyfikatora użytkownika). Mam wrażenie, że nie jest to najlepsza praktyka, ponieważ nie widzę wielu innych aplikacji klienckich przyjmujących takie podejście.

Który z nich jest lepszym rozwiązaniem, czy istnieje inne podejście, którego nie rozważam?

Odpowiedz

1

Masz rację o opcję nr 1. Nie dekoduj klienta tokena po stronie klienta. Wymagałoby to, aby kod po stronie klienta znał "tajny", który ujawniałby go każdemu, kto przeglądałby twój Javascript.

Opcja nr 2 jest dobra, zakładając, że nadal wysyłasz token z każdym żądaniem ze względów bezpieczeństwa. Do przechowywania, tak, musisz przechowywać go w ciasteczku lub w localStorage, lub jak mówisz, zostanie utracony podczas odświeżania.

Aby uzyskać identyfikator w kodzie po stronie klienta, należy po kodzie klienta odczytać go z pliku cookie/localstorage. Są na to biblioteki; reaguje-cookie czyta na przykład pliki cookie. Możesz to zrobić za każdym razem, gdy musisz uzyskać do niego dostęp, lub możesz go przeczytać raz podczas ładowania strony początkowej, a następnie wysłać do sklepu Redux.

0

W swoim końcowym /users/:id można sprawdzić, jeśli :id został dostarczony, a następnie, jeśli nie, należy wyodrębnić identyfikator z JWT tokena inaczej używać id, który został przekazany do wywołania API.

Jeśli to jest nie do przyjęcia, a następnie można użyć opcji nr 2, ale zamiast używać sessionStoragelocalStorage

+0

Odpowiadając na swoją pierwszą opcję: czy nie byłoby to sprzeczne z konwencjami REST api? Zasadniczo, jeśli nie podano identyfikatora, który będzie wyglądał jak '/ users /', mówisz, że powinien pobrać identyfikator z tokena, ale dojście do '/ users /' wskazuje, że klient chce uzyskać listę WSZYSTKICH użytkowników . – Nahro