Quando si usa Redux / Redux-Saga - le JWT devono essere impostate nei creatori / sas di azione?

0

Quasi tutti i post del blog che ho incontrato sulla gestione di auth generica che utilizza JWT in un'applicazione React / Redux / Saga fa la stessa cosa, ovvero archiviare il JWT nella memoria locale, in action / saga.

Ad esempio:

Esempio A (redux-saga) :

function* authorize({ payload: { login, password } }) {
  const options = {
    body: JSON.stringify({ login, password }),
    method: 'POST',
    headers: { 'Content-Type': 'application/json' }
  };

  try {
    const { token } = yield call(fetchJSON, '/login', options);
    yield put({ type: AUTH_SUCCESS, payload: token });
    localStorage.setItem('token', token);
  } catch (error) {
    let message;
    switch (error.status) {
      case 500: message = 'Internal Server Error'; break;
      case 401: message = 'Invalid credentials'; break;
      default: message = 'Something went wrong';
    }
    yield put({ type: AUTH_FAILURE, payload: message });
    localStorage.removeItem('token');
  }
}

function* Saga() {
  yield takeLatest(AUTH_REQUEST, authorize);
}

Esempio B ( redux):

function login(username, password) {
    const requestOptions = {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ username, password })
    };

    return fetch('${config.apiUrl}/users/authenticate', requestOptions)
        .then(handleResponse)
        .then(user => {
            // login successful if there's a jwt token in the response
            if (user.token) {
                // store user details and jwt token in local storage to keep user logged in between page refreshes
                localStorage.setItem('user', JSON.stringify(user));
            }

            return user;
        });
}

function logout() {
    // remove user from local storage to log user out
    localStorage.removeItem('user');
}

Ora - archiviando i JWT nell'archivio locale a parte - ciò che mi preoccupa - è l'impostazione dello stato all'interno del creatore / saga dell'azione - piuttosto che in un riduttore.

La mia comprensione è che i creatori di azioni / sagas dovrebbero essere usati solo per determinare i dati da utilizzare - e spetta ai riduttori memorizzare / persistere i dati.

Ora ovviamente - al suo stato iniziale, il redux non persisterà i dati. Tuttavia, puoi usare un middleware redux come redux-persist per persisterlo nell'archiviazione locale (e ci sono altri middleware redux-persist per mantenere i dati in altri posti). Il punto qui è - redux è la gestione dello stato.

Perché allora - sembra che tutti stiano semplicemente scavalcando usando redux come stato della tua applicazione quando si tratta di autenticazione?

    
posta dwjohnston 03.12.2018 - 01:19
fonte

2 risposte

1

Farò un'ipotesi da diverse fonti.

  1. Ho sentito che "la sicurezza non è una preoccupazione trasversale". Metterei l'autenticazione al suo interno. Non può essere separato dal programma sebbene non sia incluso nel modello e quindi premuto quando necessario.
  2. Se sei autenticato non fa parte del tuo modello in modo che tu abbia due oggetti, uno autenticato e uno non autenticato allo stesso tempo.

Quindi, provi a spingere l'autenticazione tanto lontano dall'altra logica. Lo metti in uno strato tra comunicazione e modello. Questo livello è così sottile che in un esempio non si fornisce spazio extra in quanto questo livello potrebbe non evolversi o evolversi in modi imprevisti nei programmi basati sull'esempio. Inoltre, ci sono solo due posti per gestire questo caso d'uso.

Un altro è che in un esempio, ti piace andare per semplicità anziché perfezione.

PS: una risposta come questa di solito porta a risposte migliori in arrivo. Buona fortuna!

    
risposta data 06.12.2018 - 02:10
fonte
1

Per me, la ragione principale per archiviare il token nella memoria locale invece che nel redux store è che sono di natura fondamentalmente diversa in quanto:

  • In genere vuoi anche mantenere il token di autenticazione tra gli aggiornamenti della pagina
  • Puoi volerlo o non farlo con lo stato dell'applicazione

A parte questo, l'impostazione dello stato nel creatore dell'azione mi sembra semplicemente sbagliata, dal momento che l'unica responsabilità di chi deve restituire l'azione.

L'impostazione dell'archiviazione locale è per definizione un effetto collaterale, quindi mi sembra che il posto logico sia nel gestore degli effetti collaterali che preferisci - in molti casi le saghe.

    
risposta data 07.12.2018 - 16:59
fonte

Leggi altre domande sui tag