Forniremo il contenuto a un Content Management System che lo incorpori attraverso un iframe (yuck). Alcune pagine che serviamo devono essere autenticate prima: solo un utente valido dovrebbe essere in grado di vederle.
L'azienda che in precedenza ha implementato ciò che stiamo per fare ha fatto questo attraverso le richieste. Certo, dal momento che non c'era la gestione delle sessioni. L'uso di iframe s ha reso impossibile l'uso dei cookie, ecc. Non è un'autenticazione reale, ma è quello che hanno fatto ...
http://example.com/get.php?ID=1234&[email protected]
Che ci crediate o no: si potrebbe facilmente ottenere il contenuto di un altro utente scambiando ID o e-mail. Ora vogliamo (o, abbiamo) di cambiarlo. Il problema è che non abbiamo accesso ai dati del cliente . Non conosciamo l'indirizzo e-mail e gli ID utente del CMS.
Il piano iniziale che era stato sviluppato era quello di inviarci un hash salato con e-mail e ID, e qualcuno ha pensato che fosse possibile estrarre nuovamente e-mail e ID dall'hash se sapessimo il sale. Bene, risulta che non sapevano come funzionano gli hash ... quindi è su di me per inventare qualcosa di nuovo.
Ecco il primo scenario a cui ho pensato:
InquestocasoriceviamosolounelencodihashvalididalCMSecontrolliamosel'hashchel'utentecihainviatoèvalido.IlproblemaquiècheabbiamobisognodiunelencodihasheilCMSdeveinviarlialnostrobackendinqualchemodo.C'èqualchealtroproblemachemimanca?Chediredegliutenticheprovanotuttiglihashpossibili?
Secondoscenario:
Riceviamo l'hash dell'utente e lo rimandiamo al CMS. Il CMS verifica che questo hash esiste davvero e ci dice se possiamo servire il contenuto. Qui, il problema è che devono essere fatte richieste extra (performance?).
Terzo scenario, che a mio avviso dovrebbe adattarsi al nostro caso:
L'utente ci invia la sua e-mail, l'ID e l'hash che il CMS ha generato per loro. Condividiamo una chiave segreta (il sale) con il CMS e proviamo a ricostruire l'hash da e-mail e ID. Se corrisponde, l'utente deve essere stato autenticato nel CMS prima, quindi possiamo pubblicare il contenuto.
Il problema qui è che inviamo l'e-mail tramite URL. Ora, anche l'implementazione precedente (non sicura) ha funzionato, ma non so quanto questo sia un problema di privacy.
Conclusione: c'è qualcosa che ho perso negli esempi sopra? L'ultimo scenario sarebbe adatto al nostro caso, oppure esiste un altro metodo semplice per autenticare un utente quando non hai accesso ai dati privati sul tuo lato dello schema?
