Come autenticare le richieste utilizzando ServiceStack, il proprio repository utente e gli ID dispositivo?

Question

Sto creando un'app mobile e un back-end del servizio Web di ServiceStack. Il materiale di Autenticazione in ServiceStack sembra fantastico ma facile da perdersi nella sua flessibilità: una guida molto apprezzata. Utilizzerò le mie tabelle db per archiviare gli utenti ecc. All'interno del servizio web. Mi piacerebbe avere un processo di registrazione e la successiva autenticazione qualcosa di simile:

• l'utente fornisce inizialmente solo un indirizzo e-mail, il mio servizio web quindi messaggi di posta elettronica un codice di registrazione per l'utente
• l'utente inserisce la chiave . L'app invia al servizio web per la registrazione: email, chiave & un identificativo univoco del dispositivo.
• il servizio Web verifica la chiave e memorizza l'e-mail ID dispositivo &. Risponde con un token di autenticazione che l'app utilizzerà per un'autenticazione successiva.

Quindi le richieste di servizi Web successive fornirebbero l'id del dispositivo e il token di autenticazione (o un hash creato con esso). L'app non è molto loquace quindi sono tentato di inviare i dettagli di autenticazione su ogni richiesta web.

Domanda 1: devo collegarmi all'API di registrazione di ServiceStack o semplicemente aggiungere un paio di chiamate di servizi Web personalizzate? per esempio. senza utilizzare la registrazione di ServiceStack vorrei:

• inviare a un servizio Web di registrazione con l'indirizzo di posta elettronica e l'id del dispositivo. Il mio servizio web invierà l'e-mail di registrazione con una chiave e aggiungerà un record alla tabella db dell'utente.
• quando l'utente inserisce la chiave, invierà di nuovo al servizio web di registrazione, questa volta anche con la chiave. Il mio servizio web convalida la chiave e aggiorna la tabella utente contrassegnando l'utente come registrato, creando e registrando il token di autenticazione restituendolo al chiamante
• richieste successive verrebbero inviate utilizzando http basic auth con l'id del dispositivo come nome utente e il token auth come password. Il servizio non è molto chiacchierone, quindi i crediti verranno inviati ad ogni richiesta.
• Implementerò un CredentialsAuthProvider che otterrà i crediti con httpRequest.GetBasicAuthUserAndPassword() e li convaliderà con i dati del database.

Ma sembra che dovrei usare la registrazione integrata in ServiceStack.

Domanda 2: Cosa c'è di sbagliato nel passare i dettagli di autenticazione con ogni richiesta? Ciò renderebbe più semplice la composizione delle mie richieste di app, ma non sembra "fatto" sulla base degli esempi di ServiceStack. Presumibilmente perché è inefficiente se hai molte richieste di cui hai bisogno per ri-autenticare ogni chiamata - per altri motivi? La mia app eseguirà solo una singola richiesta web al massimo ogni pochi minuti, quindi sembra più semplice evitare di avere sessioni e solo ri-autorizzare ogni richiesta.

Domanda 3: Sono sulla giusta sottoclasse di CredentialsAuthProvider?

Domanda 4: C'è qualche punto che utilizza il token di autenticazione per generare un hash invece di inviare il token di autenticazione ogni volta? Tutte le comunicazioni saranno sopra https.

Answer 1

Answer1: Sarà OK. se si danno più chiamate secondo il requisito. Normalmente l'autenticazione funziona in base al cookie, ora puoi salvarlo sul client e/o sul server e abbinare l'utente con esso. Anche in questo caso, se si utilizza il dispositivo, è possibile utilizzare sempre il dispositivo anziché l'utente per mappare e autenticare l'utente. In base alle vostre esigenze

Preferisco utilizzare il provider poiché nasconde molti dettagli che è necessario eseguire manualmente. Sei sulla buona strada. Esistono molti blog specifici per l'autenticazione e come creare un'autenticazione personalizzata con lo stack di servizi. Se ti va fammi sapere che ho un libro contrassegnato con qualcuno che te lo darà. Il modo migliore per cercare l'ultimo è il checkout dell'account Twitter di Servicestack.

Answer2: Questo è di nuovo, dico come da requisito. Ora se il tuo utente sarà solo nella zona Wi-Fi. (Principalmente vero per gli utenti business), quindi non c'è limite per le chiamate. Basta dare una chiamata API e fare l'autenticazione in background. Il token JSON semplice non farà male, solo pochi byte. Ma ancora una volta se hai una grande base di utenti che non sta usando una buona connessione internet, allora sarà meglio memorizzare i dettagli di autenticazione sul dispositivo e verificarlo. Solo per salvare una chiamata di rete. In ogni caso la chiamata di rete è pesante in termini di risorse.

Answer3: Sì, sei sulla buona strada. Continua a leggere i post sul blog per ulteriori dettagli. Non ricordo lo snippet di codice e come funziona con l'ultimo aggiornamento, quindi non sto inserendo il codice qui.

Answer4: Questa è la risposta è poco complicata. Passare i dati su https e salvare l'utente dalla frode di Identity è una cosa poco diversa. Ora, se non stai generando un token di autenticazione (valore basato su hash), puoi passare l'utente anche tramite http o https. Ora, questo può essere usato da un altro utente per simulare il primo utente e inviare dati. Anche i dati vengono passati attraverso https ma i dati vengono comunque derisi. Il valore basato su Hash viene utilizzato per evitare questa situazione. E inoltre ci sono un paio di altri casi d'uso aziendali che possono essere coperti usando il token di autenticazione.

Per favore fatemi sapere se ho capito bene le vostre domande e risposto loro ?? o se sono necessari ulteriori dettagli ??