Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 19
  1. #1
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502

    Struttura db per login da più pc

    Ciao a tutti, Sto cercando in rete qualche possibile esempio per strutturare un sito web in moto che mantenga gli accessi di ogni utente (anche multipli, ad esempio user1 loggato sia da PC che da tablet). Purtroppo non è la stessa cosa della struttura che mantiene un solo accesso per utente. Come posso fare?
    Personal Home Page

  2. #2
    direi che dipende dalla logica del programma, dacci qualche indizio in più

  3. #3
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502
    Ciao optime, grazie !
    ti spiego: precedentemente appena facevo l'accesso salvavo sid uid e expires in una tabella session, e ad ogni refresh aggiornavo la tabella cancellando i vecchi row dell'utente (expires < Now() And uid = id_user). In questo modo, con le opportune verifiche, permettevo un singolo accesso ad ogni utente per una sola macchina. Se si esegue l'accesso altrove, si autoslogga il vecchio. E così funziona perfettamente, oltretutto nella tabella session ho tutti gli ultimi accessi (posso fare la statistica delle persone online, ultimo accesso, ecc).

    Ora, mi chiedevo: come strutturo invece le tabelle se volessi permettere più accessi attivi ad un singolo utente su macchine differenti? Magari salvando l'user agent di ogni sessione per capire da quale macchina è stato effettuato e la possibilità da un pannello di controllo di sloggarle "a distanza".
    Avevo pensato di creare una tabella cookie dove mettere una stringa alfanumerica (il contenuto del cookie salvato) ed il suo ID, al fine di non salvare dati sensibili direttamente sulla macchina. Così un user può avere più cookie. Ora, se aggiornassi le pagine, modifico quel row. Se sloggo, posso cancellarlo. Ma se il cookie mi scade, sono costretto a rifare l'accesso, creare un nuovo row ed il vecchio rimarrebbe lì per sempre, 'intasandomi' la tabella. Potrei fare anche uno script che pulisce tutti quelli scaduti ma mi sembra poco chiaro. Cosa suggerisci?
    Personal Home Page

  4. #4
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502
    Nessuno ha qualche idea? Anche se facessi così come ho descritto, eliminando meccanicamente allo scadere del cookie, non saprei mai con precisione quante sessioni ho aperto (perchè potrebbe segnarmi quel falso positivo come una session in più)
    Ultima modifica di Vash SD; 11-01-2015 a 11:43
    Personal Home Page

  5. #5
    Utente di HTML.it L'avatar di clasku
    Registrato dal
    Aug 2006
    Messaggi
    3,197
    salvati la data di scadenza del cookie nel db e gestiscila come facevi prima
    ogni volta che un utente fa un'azione, aggiorni la data del suo cookie, controlli quelle degli altri e nel caso cancelli (magari non usare NOW() secco, aggiungici un intervallo di tempo a tua scelta)
    ovviamente dovrai gestire il controllo sul cookie nei vari client, se non esiste più gli fai rifare il login

    PS: probabilmente, se fossi utente dell'applicazione ti odierei dal profondo XD

  6. #6
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502
    Si esatto come hai detto tu funziona perfettamente; se volessi fare un pannello dove gestire tutti gli accessi attivi mi basterebbe fare poi una SELECT basata sull'id, ma in questa caso potrei essere soggetto a falsi positivi Perchè metto un cookie di 30 giorni, l'utente pulisce i cookie e non ha quindi più l'accesso ma il suo cookie nel db esiste. Faccio la select e trovo un punto di accesso in più :/ quindi la soluzione è certamente non fare questo pannello di controllo, ma deve esserci un modo per farlo!

    Ps come mai mi odieresti? XD
    Ultima modifica di Vash SD; 11-01-2015 a 12:34
    Personal Home Page

  7. #7
    Utente di HTML.it L'avatar di clasku
    Registrato dal
    Aug 2006
    Messaggi
    3,197
    mi autoquoto, precisando che la scadenza nel DB può anche essere uguale al momento di scrittura del record.
    ogni volta che un utente fa un'azione, aggiorni la data del suo cookie, controlli quelle degli altri e nel caso cancelli (magari non usare NOW() secco, aggiungici un intervallo di tempo a tua scelta)
    cancelli dal DB il/i record degli altri, il cookie sul client puoi anche metterlo a scadenza immediata (tipo a chiusura browser)

    i falsi positivi sarebbero limitati al tempo che tu decidi di aggiungere a NOW() quando verifichi la data del cookie registrato sul DB

  8. #8
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502
    Perdonami, ma non capisco cosa intendi per cancellare quelli degli altri. Purtroppo non posso perchè se li cancellassi ogni utente privato di quel row mi risulterebbe come un falso cracker. Ti spiego: nel cookie c'è salvato una stringa alfanumerica case sensitive che deve essere letta messa in corrispondenza con quella del db per sapere che id utente è. Tutto ciò (ho pensato, ma capisco che posso chiaramente sbagliare xD) è una sicurezza in più perchè evito una sorta di cookie manipulation
    Personal Home Page

  9. #9
    Utente di HTML.it L'avatar di clasku
    Registrato dal
    Aug 2006
    Messaggi
    3,197
    Io intendo questo (ipotizzando che tutti abbiano fatto un accesso contemporaneo e che si sia in una LAN interna, per l'esterno l'IP potrebbe essere un dato non valido):

    • utente A -> accesso da PC con IP *.1 -> registro un cookie sul client con valore "Az" e salvo le stesse informazioni sul DB (IP, valore cookie, data/ora di accesso, data di aggiornamento del record - valorizzata con NOW() al momento dell'insert);
    • utente B -> accesso da smartphone con IP *.2 -> registro un cookie sul client con valore "Bz" e salvo le stesse informazioni sul DB (IP, valore cookie, data/ora di accesso, data di aggiornamento del record - valorizzata con NOW() al momento dell'insert);
    • utente A -> accesso da tablet con IP *.3 -> registro un cookie sul client con valore "Cz" e salvo le stesse informazioni sul DB (IP, valore cookie, data/ora di accesso, data di aggiornamento del record - valorizzata con NOW() al momento dell'insert);
    • utente A -> dopo 3 minuti fa un'operazione -> cerco il valore del suo cookie nel DB, controllo la congruenza delle informazioni (il suo IP è lo stesso di prima?), aggiorno la data di aggiornamento del suo record e controllo che gli altri client siano ancora da ritenere attivi (query di delete su record con data di aggiornamento <= NOW() + 5 minuti) - non dovrò fare nulla, dato che sono passati tre minuti;
    • utente A -> dopo 2,5 minuti fa un'altra operazione -> cerco il valore del suo cookie nel DB, controllo la congruenza delle informazioni (il suo IP è lo stesso di prima?), aggiorno la data di aggiornamento del suo record e controllo che gli altri client siano ancora da ritenere attivi (query di delete su record con data di aggiornamento <= NOW() + 5 minuti) - dovrò cancellare i due record relativi a utente A da tablet e utente B da smartphone;
    • utente B -> dopo la cancellazione del suo record fa un'operazione -> cerco il valore del suo cookie nel DB, non lo trovo perché l'ho cancellato prima e lo forzo a rifare il login, registrando nuovamente un record per il suo client con il nuovo valore del cookie che gli ho impostato sulla macchina.


    PS: il cracker lo dovresti fregare comunque, dato che la stringa che registri sul cookie sarà randomica e lui dovrebbe avere accesso ad altro dispositivo con cookie valido e ancora presente sul DB

  10. #10
    Utente di HTML.it L'avatar di Vash SD
    Registrato dal
    Sep 2006
    Messaggi
    502
    Innanzitutto, grazie mille per la disponibilità e l'aiuto.Questo funzionerebbe a meraviglia e ho capito anche perchè mi odieresti e mi odierei anche io, ma io vorrei trovare un modo (conta che gli IP possono essere dinamici perchè é un sito web e gli utenti con provider di IP dinamico possono riscontrare problemi) tale che mi permetta di lasciare il poraccio di B loggato !
    Personal Home Page

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.