Ho ereditato una semplice app web a pagina singola. Gli utenti non effettuano l'accesso: una volta che hanno l'URL, possono consultare l'app (molto semplice). L'app comunica con un'API Java.
Solo un po 'di storia: l'app è stata lanciata molto velocemente, quindi il team di sviluppo è stato rilasciato due mesi dopo. Sospetto che ci siano dei buchi nell'architettura.
Gli sviluppatori precedenti hanno implementato una sorta di architettura di login anonima che non riesco a capire.
Lascia che te lo spieghi:
In primo luogo, tutte le richieste all'API devono includere un'intestazione authorization e una userId nell'URL della richiesta, altrimenti falliscono. Quindi, al momento, il codice effettua le seguenti operazioni:
1 / Nel browser client, la memoria locale viene controllata per la presenza di accessToken e userId . Se viene trovato accessToken , viene inviato come valore per l'intestazione authorization e, se viene rilevato userId , viene inviato nell'URL.
2 / Se accessToken non viene trovato nella memoria locale, un UUID casuale di 36 caratteri viene generato dal javascript e inviato in una richiesta POST a un endpoint chiamato login . Un'altra proprietà inviata nella richiesta POST si chiama merchant , il cui valore dipende dall'URL del web - ci sono 6 diverse varianti (solo loghi e stili diversi) dell'interfaccia utente con URL diversi. Quindi merchant può essere 1 di 6 valori.
3 / Nel gestore login sul lato server, viene creato un utente. Il server quindi genera il proprio UUID e lo imposta come una proprietà dell'utente. Anche merchant è impostato come proprietà dell'utente. Un token di accesso viene quindi generato da un servizio token con una data di scadenza (in 60 giorni), un segreto e l'UUID generato dal server. Il token di accesso è impostato come una proprietà dell'utente e l'utente viene quindi salvato in una tabella di database. Il token di accesso viene restituito al client, insieme a una proprietà chiamata userId , che è l'UUID generato dal server.
4 / Ora tutte le richieste API successive vengono eseguite con il token di accesso nell'intestazione authorization e il userId nell'URL di richiesta API, ad es. www.my-api-base-url/v1/abc-123/product dove abc-123 è userId .
5 / Sul lato server, l'intestazione authorization viene controllata dal servizio token per vedere se è valida, e viene quindi analizzata per ottenere l'UUID. Viene quindi confrontato con l'UUID nell'URL.
In primo luogo, sospetto che ci sia un bug qui - l'UUID generato dal javascript è ignorato e il server genera il proprio UUID. Pertanto, non possiamo sapere se le richieste successive provengono dallo stesso cliente dalla richiesta di login . È corretto?
In secondo luogo, perché abbiamo bisogno del userId nell'URL? L'intestazione authorization non è sufficiente?
In terzo luogo, qual è il principio principale alla base di questo tipo di architettura di login anonima? È per assicurarsi che le richieste successive provengano dallo stesso cliente dalla richiesta di login ? È tutto? C'è qualche altro ragionamento dietro di esso?