Ciao! Domanda sempre molto terra terra: ma secondo voi, poste le seg.
condizioni:
Qual’è il modo + veloce e sicuro per gestire il login/out? Dove li salvo
nome utente e password? Che tipo di misure di sicurezza prendo?
Se c’è un utente o 10 o 100.000+
la gestione della sicurezza è sempre la stessa.
Architect
2010/1/11 Luca R. [email protected]
2010/1/11 Luca R. [email protected]
Se sei sicuro che l’utente sia uno, o qualcosa del genere, potresti fare
a
meno del tutto di preoccupartene dentro rails, e usare invece
l’autenticazione http del web server… ti semplifichi la vita!
Ciao
On 11/01/2010 11:46, Luca R. wrote:
per user e password, se proprio sei certo che si tratta di un solo
utente e non vuoi scomodare una tabella sul database, puoi sempre
usare un file, magari al suo interno la password la codifichi a monte
con MD5, un po’ come /etc/shadow sui *nix 
per tutto il resto, la prassi è quella di un db.
non la considererei una best practice, ma se è quello che vuoi
ottenere, una strada potrebbe essere questa 
ciao,
A.
con la basic authentication
non c’è possibilita di logout, ossia se non chiudi il browser rimane
loggato,
a parte questo piccolo problema è una scelta ottima
Architect
2010/1/11 Luca De Marinis [email protected]
Ah dai questa cosa non la sapevo. Ma con la basic authentication, la
sicurezza della password come viene getita? Cioé, è sicura la cosa?
Scusate le domande sceme, ma il fatto è che pur essendo un buon (credo)
programmatore javascript/actionscript, al server-side mi sto avvicinando
ora.
Simone F. wrote:
con la basic authentication
non c’� possibilita di logout, ossia se non chiudi il browser rimane
loggato,
a parte questo piccolo problema � una scelta ottimaSimone F.
Architect
2010/1/11 Luca De Marinis [email protected]
la basic authentication è gestita dal browser l’autenticazione passa
codificata nell’header della request
la codifica è base64, e ovviamente esiste una decodifica… non stiamo
parlando di criptatura quindi
non menzionerei la sicurezza quando si parla di basicautentication.
non è sicura, o meglio se il tuo cliente passa da un proxy o c’è un
attacco
man in the middle, chi è in mezzo ha la possibilità di loggarsi con il
tuo
account senza nessuna fatica.
se invece c’è SSL, reperire la password che passa codificata è molto più
difficile.
rimane però il problema del logout
Architect
2010/1/11 Luca R. [email protected]
Firefox ha un’estensione chiamata web developer toolbar. Installa per
l’appunto una toolbar con un menu Miscellaneous, Clear Private Data…,
HTTP Authentication che cancella le credenziali di autenticazione HTTP
senza dover chiudere il browser. Comodo per chi sviluppa.
A parte questo, trattandosi di un’applicazione per un solo utente le
fasi di login e di logout possono essere facilmente controllate per cui
anche chiudere il browser potrebbe essere accettabile. L’unico vero
problema è l’invio in chiaro della password, cosa che fanno anche i
soliti form di autenticazione web a meno che i dati non viaggino su
https.
Di nuovo, trattandosi di un’applicazione mono utente potresti generarti
il tuo certificato per l’HTTPS e installarlo sul server e sul client. In
questo modo fai SSL senza pagare Verisign & Co.
Paolo
Simone F. wrote:
la basic authentication è gestita dal browser l’autenticazione passa
codificata nell’header della request
la codifica è base64, e ovviamente esiste una decodifica… non stiamo
parlando di criptatura quindi
non menzionerei la sicurezza quando si parla di basicautentication.non è sicura, o meglio se il tuo cliente passa da un proxy o c’è un
attacco
man in the middle, chi è in mezzo ha la possibilità di loggarsi con il
tuo
account senza nessuna fatica.se invece c’è SSL, reperire la password che passa codificata è molto più
difficile.
rimane però il problema del logoutSimone F.
Architect
2010/1/11 Luca R. [email protected]
Grazie dell’ampia spiegazione!
Ma tipo, lasciando stare per un momento la transazione e la basicauth:
user e pass, non posso salvarli come costanti nel controller dell’admin
(sempre per via del fatto che l’utente lo decido io ed è unico)? Li
intanto sono al sicuro giusto?
Poi ovviamente devo assicurarmi che non vengano pescate dalla request.
Luca
Simone F. wrote:
la basic authentication è gestita dal browser l’autenticazione passa
codificata nell’header della request
la codifica è base64, e ovviamente esiste una decodifica… non stiamo
parlando di criptatura quindi
non menzionerei la sicurezza quando si parla di basicautentication.non è sicura, o meglio se il tuo cliente passa da un proxy o c’è un
attacco
man in the middle, chi è in mezzo ha la possibilità di loggarsi con il
tuo
account senza nessuna fatica.se invece c’è SSL, reperire la password che passa codificata è molto più
difficile.
rimane però il problema del logoutSimone F.
Architect
2010/1/11 Luca R. [email protected]
puoi fare quello che credi
metterle in un file, metterle Hard Coded dentro il Controller,
quello che vuoi.
io però le metterei alla classica maniera sul DB.
ciao
S
Architect
2010/1/11 Luca R. [email protected]
se vuoi puoi anche fare la stessa cosa direttamente da rails usando
authenticate_or_request_with_http_basic
2010/1/11 Andrea P. [email protected]:
Un’ultima domanda veramente da asini, così ti rendi conto di come son
messo sul piano server-side… : in linea teorica, il codice dei
controller, dei models e in generale i file .rb non sono accessibili a
possibili attacchi giusto? Cioé, nessuno è in grado di vedere
materialmente le parti in ruby, o sbaglio? In generale, quali sono le
aree di norma ‘nativamente’ quasi o completamente immuni da potenziali
attacchi diciamo ‘convenzionali’?
Simone F. wrote:
puoi fare quello che credi
metterle in un file, metterle Hard Coded dentro il Controller,
quello che vuoi.io per� le metterei alla classica maniera sul DB.
ciao
SSimone F.
Architect
2010/1/11 Luca R. [email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs