In sostanza, stai utilizzando il tuo sistema di accesso per realizzare due obiettivi separati:
- Autentica utenti normali
- Consenti agli utenti ospiti di accedere a pagine altrimenti autenticate
Come regola generale usando una cosa per due scopi tende a causare i suoi problemi a lungo termine, e quindi se non altro il SRP suggerisce che questa è una pessima idea. Ci sono certamente molti modi in cui questo può causare problemi:
- Avrai ancora bisogno di controlli di accesso per assicurarti che gli utenti di questo account ospite non abbiano accesso ad altri endpoint API che non dovrebbero essere accessibili a loro. Questo, in effetti, sarebbe probabilmente la mia più grande preoccupazione: quando si scrive un nuovo endpoint dell'API sarebbe molto facile dimenticare "Ehi, abbiamo utenti ospiti che usano questo altro accesso speciale" e quindi dimenticare di impedire l'accesso a una nuova API per ha detto gli utenti ospiti. Se quell'API capita di trattare con informazioni sensibili, allora si può effettivamente finire con una violazione pubblica e critica dei dati.
- Consentendo a molti utenti di condividere un account, i registri di controllo e di accesso ai dati diventano molto più complessi da implementare in modo efficace.
- Se è necessario modificare le credenziali dell'account guest, non è possibile farlo senza disconnettere tutti gli utenti guest attivi
Ci sono due percorsi alternativi che puoi prendere:
1. Separare gli endpoint che non richiedono l'accesso
Questo ha molti vantaggi. Certo, è necessario creare un set separato di endpoint, ma aggiungerà un livello tra gli utenti non autorizzati e i sistemi autorizzati. Ciò rende entrambi più difficile per loro trovare potenziali punti deboli di sicurezza (poiché sono limitati a un sottoinsieme molto più piccolo del tuo sistema) e rende anche più difficile per i tuoi sviluppatori sbagliare. Quando c'è una netta separazione tra, ad es. "Questo codice è per gli utenti autorizzati" e "Questo codice è per gli utenti non autorizzati", quindi è più difficile per qualcuno dimenticare quale parte stanno lavorando e fare un errore di sicurezza di conseguenza (notare che ho detto più difficile, non impossibile). In questo modo sarà più semplice proteggere in modo sicuro i tuoi endpoint, anche se non è possibile quantificare con precisione il risultato finale.
2. Account guest separati per ogni utente con controlli di accesso limitato
Non c'è un sacco di background nella tua domanda, ma basandomi su quel poco che riesco a vedere, probabilmente questo non ha senso per te. Comunque ho pensato che non facesse mai male parlare di cose. Un'altra opzione è semplicemente creare un account ospite separato per ogni utente "ospite" del tuo sistema. Funziona meglio se il tuo sistema ha già dei controlli di accesso chiari (in modo da poter bloccare con sicurezza tali utenti da luoghi che non dovrebbero essere) o se usati in combinazione con un set separato di endpoint API (ad esempio, gli utenti ospiti sono automaticamente bloccato da tutti gli endpoint tranne questi pubblici).
Finisci con un po 'più di codice per gestire in questo modo (al contrario di avere solo alcuni endpoint completamente aperti) ma ha alcuni vantaggi:
- Puoi tenere traccia in modo più nitido degli utenti guest nel tuo sistema, presumendo che stai già monitorando gli utenti in base ai loro accessi
- Se hai un concetto di "conversione" di questi utenti ospiti in utenti completi del tuo sistema, avrai già a metà il processo quando arriva il momento della conversione, e poi sarai in grado di tracciare facilmente la cronologia di un utente da prima ancora si sono ufficialmente registrate.
- A seconda di come un utente diventa uno di questi account guest, i tuoi endpoint "pubblici" non devono essere effettivamente completamente aperti. Cioè se un utente fa clic su un pulsante su "Accetta termini e condizioni" e quindi diventa automaticamente un utente ospite, e devi essere un utente ospite per accedere a queste pagine "pubbliche", avrai effettivamente espulso la maggior parte dei bot e lo scraping automatico sistemi dai tuoi endpoint.