Devo trattare un lavoratore come un altro 'utente' nel mio sistema?

Question

Devo trattare un lavoratore come un altro 'utente' nel mio sistema?

#1 da (6 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (1 voti)
#5 da (1 voti)

6

Fondamentalmente sto progettando un'applicazione abilitata per il web che dovrebbe avere un'API nel mezzo. Ho trovato questa domanda su Stack Overflow , che sfortunatamente non ha risposte.

Diciamo che c'è un sistema, simile a questa immagine:

Ilcentro"API" è fondamentalmente un server HTTP scritto con uno dei framework RESTful in una lingua. La "Web App" è fondamentalmente un altro "Client", quindi dovremmo trattarlo allo stesso modo.

Ora, diciamo che i miei clienti (iOS, Android, Web) si connettono tramite OAuth2 e comunicano con un server RESTful basato su JSON. Tutto buono e logico, ogni nuovo 'utente' ha una chiave API assegnata a loro, quindi quando un utente esegue un'operazione, ovvero viewOrder (333), il sistema registra che "utente 'xxx' a H: i: s tempo richiesto ordine n. 333 ". Ancora buono.

Quindi abbiamo dei lavoratori ed è qui che risiede la mia domanda principale. Dire ai lavoratori di eseguire l'elaborazione degli ordini, ad esempio un lavoratore che controlla lo stato di pagamento di un ordine. Quello che fa il lavoratore è il controllo di nuovi pagamenti (correlati) in un sistema esterno e li spinge a un server di accodamento per l'elaborazione successiva. Un altro lavoratore (o lo stesso, forse?) Controlla costantemente la coda per i pagamenti appena aggiunti, li preleva dalla coda, esegue tutto il processo e, se tutto è corretto, aggiorna il DB con il nuovo stato dell'ordine, i soldi pagati, ecc, ecc. ...

Quindi la mia domanda è: dovrei trattare un lavoratore come un altro 'utente' nel mio sistema? Dì "system_user_1" che è responsabile per l'elaborazione degli ordini. Questo utente di sistema dovrebbe anche autenticarsi con OAuth2 come il resto di loro? È anche corretto avere questo 'utente di sistema' nel sistema? Quali sono gli svantaggi della sicurezza? Quali sono le altre possibili implicazioni di un simile sistema? O sto sbagliando tutto questo e c'è una soluzione completamente diversa al mio problema?

P.S. Questo sistema deve essere scalabile e potenzialmente potrebbe ridimensionarsi molto velocemente, quindi questo è un tentativo di creare una soluzione a lungo termine. Idealmente ci saranno più istanze del server 'API' con il bilanciamento del carico di nginx per carichi elevati.

architecture api rest backend oauth2

posta lime 11.07.2016 - 17:17

fonte

5 risposte

Leggi altre domande sui tag architecture api rest backend oauth2

Va bene avere più metodi di azione get nel controller ASP .Net Web API in base ai vincoli RESTful API? Quali sono le insidie più comuni dello sviluppo del cloud in cui ti sei imbattuto?

score 6 · Answer 1

La risposta "giusta" quasi sempre ha gli edge autentici con qualche tipo di account utente o altro meccanismo di autenticazione.

Perché? Perché è possibile limitare l'accesso di quella specifica interfaccia di bordo ai soli dati di cui hanno bisogno con gli ambiti giusti. Ad esempio, un lavoratore aggiorna solo gli ordini ma non può visualizzare le informazioni di pagamento. Se c'era un compromesso del lavoratore non è possibile aggiornare gli ordini, contrassegnandoli tutti pagati. O strapagati, innescando un rimborso.

Questo non sempre significa utenti reali. Forse si assegnano le chiavi di accesso ai lavoratori, ma si può ancora limitare ciò che può fare la chiave di accesso e revocare uno dei necessari.

In conclusione, se l'API è il tuo nucleo, toccarlo tutti dovrebbe toccarlo in qualche modo che ti consenta di

limite di copertura in caso di violazione o exploit e
revoca l'accesso se il token o l'endpoint sono compromessi in qualsiasi modo.

score 3 · Answer 2

Ecco come progetto un sistema simile:

Cliente: ios / Android / altri client mobili interagiscono con la mia API per fare ordini o visualizzare ordini

API: backend Servizio valido che gestisce le richieste dei client e dell'interfaccia utente. Se gli ordini devono essere elaborati in modo asincrono, dovremmo usare Code, dalla domanda che ottengo che gli ordini sono gestiti in modo asincrono.

L'API dovrebbe mantenere le richieste di ordine nel DB con lo stato non elaborato e tenerle in coda (come Amazon SQS, RabbitMQ ecc.) e quindi i lavoratori dovrebbero prelevarle dalla coda elaborarle e aggiornare il DB. Non dobbiamo esporre l'API di elaborazione perché ciò può causare problemi di sicurezza.

score 1 · Answer 3

Ho sempre avuto la flotta di lavoratori che interagiscono direttamente con il database (o la coda, qualunque sia lo stato dell'ordine), che potrebbe semplificare l'accesso. Ma nei registri, si vuole essere sicuri di poter nominare e risalire ai lavoratori, per il controllo di un flusso di ordini. Inoltre, è necessario sincronizzare i lavoratori che lavorano e i client che acquisiscono lo stato tramite l'API. Se si dispone di una singola identità di rete (come un utente LDAP) condivisa tra i lavoratori, la questione su quale operatore ha eseguito quale ordine e quando diventa dipendente dai nomi host o dagli indirizzi IP per distinguere i lavoratori nei registri. È più semplice se i log provengono dai lavoratori piuttosto che dall'API. Ad esempio, qual è l'indirizzo di origine di una richiesta API HTTP se un proxy o un servizio di bilanciamento del carico si trova di fronte ai server API?

Se dai a ciascun lavoratore la propria identità di rete, questo cambia le cose. Ma poi devi preoccuparti di assicurarti che nessuno blocchi il tuo partito fingendo di essere un lavoratore.

score 1 · Answer 4

La ragione per cui non è stata data risposta è che sembra che stia mescolando diversi livelli di astrazione.

È comune avere diverse categorie di utenti. In questo caso vedo tre categorie di utenti dell'API:

App Web
Client (può utilizzare interfacce diverse dall'app Web)
Lavoratori (possono accedere alle API utilizzando un'app o un client Web)

Potrebbe essere meglio concettualizzare il modello per ruolo. Questi sembrano essere almeno ruoli:

Ordina i siti: app Web, client
Ordina i processori: i lavoratori (potrebbero esserci ruoli diversi per i diversi lavoratori.)
Client di database: API

Nel diagramma i Placers di ordine sono stati modellati dall'interfaccia anziché dal ruolo. I lavoratori possono effettivamente utilizzare un'app Web e / o un client.

score 1 · Answer 5

Solitamente yes.

In realtà, di solito è la soluzione più semplice , perché i meccanismi di autenticazione e autorizzazione devono essere costruiti e testati comunque. E, direi che si tratta della soluzione predefinita a meno che non vi siano motivi validi per aggirare le normali regole auth *.

L'alternativa è aggiungere un altro insieme di moduli di autenticazione e autorizzazione, aumentando la complessità complessiva del sistema e il carico di manutenzione.