HTTP L'autenticazione di base è soggetta a attacchi di tipo eavesdropping e man-in-the-middle. Si consiglia di utilizzare HTTPS.
Tuttavia, se questa non è un'opzione, è sempre possibile inviare un cookie al client e inserire il nome utente/password per impedire che venga visualizzato nel file JS. Va da sé che la password dovrebbe essere almeno criptata/hash per motivi di sicurezza. Quindi, l'onere sarà sul lato server per ottenere i dettagli di autenticazione dal cookie.
Ora, se non si ha alcun controllo sulla modifica del codice lato server, si rimane praticamente senza altra opzione se non seppellire i dettagli delle credenziali in un metodo globale ajaxSend() che invierà i dettagli nome utente/password ad ogni Richiesta AJAX. Potresti semplicemente metterlo in qualche altro file .js e renderlo difficile da trovare, ma sei praticamente limitato a quella forma di sicurezza. Anche se i cookie non rendono la vita più sicura. (Sarebbe bello se la password fosse hash/cifrata).
L'altra cosa che si può fare è avere una forma di sicurezza leggermente più complicata: avere il server che invii un nonce a ogni risposta: il nonce verrebbe "firmato" dal server usando la chiave segreta del server e si può utilizzalo per "criptare" il nome utente/password sul lato client per ogni richiesta. Il tuo server dovrebbe quindi decrittografare costantemente le credenziali. Questo è meno incline a man-in-the-middle ma non è infallibile.
HTTPS ti salverà da ciascuno di questi se è un'opzione per te.
Spero che questo aiuti.
UPDATE(come da commento): L'essenza del ristoratore-ness è l'assenza di stato sul server. No, nessuna sessione! Quindi è necessario inviare le credenziali dell'utente con OGNI richiesta che il client fa del server. Se si dispone di una pagina di accesso, è molto difficile essere veramente riposanti poiché non vi è alcuna risorsa chiamata login. Tuttavia, ecco cosa si può fare:
- visite utente di accesso pagina, immette le credenziali e clic 'login'
- invia richiesta POST al server con queste credenziali - probabilmente a/Login
- che il server restituisce il risorsa richiesta per la quale era necessaria l'autenticazione E impostare il cookie con le credenziali valide da utilizzare nella richiesta 'successiva'
- Ogni richiesta successiva verrà indirizzata alla risorsa corrispondente in un particolare URL con una particolare azione (GET, PUT, POST , ELIMINA...). Il server dovrebbe verificare i dati di autenticazione dal cookie e decidere se l'utente è autenticato ed eseguire ulteriori autorizzazioni per concedere l'accesso in caso di necessità.
Ogni richiesta deve identificarsi senza avere il server di mantenere la sessione - che è lo spirito di apolidia (e riposante-ness;)
Non rompe l'intera RESTFULness del server? Voglio dire, se hai intenzione di seguire questa strada, puoi anche fare una sessione di gestione sul server. Non fraintendermi, sono ancora all'oscuro se passo le credenziali ogni volta, archiviarle sul client per passare ogni volta non è necessariamente l'idea più brillante. – thenetimp
Non c'è niente di sbagliato nel trasferire le credenziali in ogni richiesta. In REST, ogni richiesta dovrebbe essere auto descrittiva (per rimuovere la necessità di sessioni nel server).Se una risorsa è protetta, le credenziali fanno parte della "descrizione" della richiesta e, in quanto tale, devono essere inviate con essa. Puoi semplicemente chiedere all'utente le sue credenziali e passarle su ogni richiesta successiva. Per OP, non utilizzare le sessioni, per favore. Stai distruggendo la bellezza REST con esso. Non hai bisogno di sessioni e non utilizzandole stai mantenendo il tuo sistema molto più scalabile. – miguelcobain
Puoi fornire un esempio del codice backbone.js che hai scritto per questa implementazione? Sto avendo problemi a farlo funzionare. Puoi vedere i miei progressi in [questa domanda] (http://stackoverflow.com/questions/14752326/adding-http-basic-authentication-header-to-backbone-js-sync-function-prevents-mo) – MusikPolice