Newsgroup: it.comp.www.php
Titolo: Limitare connessioni a uno stesso utente

Ciao,
ho un cliente che mi chiede di limitare in qualche modo l'accesso al
suo sito da parte degli utenti.
Gli utenti pagano per registrarsi e non vuole che piu utenti
utilizzino lo stesso username e password.
Gli ho spiegato che è difficile limitare questa cosa, ma ho pensato
che perlomeno potrei vietare più connessioni contemporanee con lo
stesso username.
Solo che non so bene come procedere...
Voi che metodo adottereste? A livello concettuale intendo.
Grazie!
-----------------
Alessio


Ovviamente devi memorizzare ogni accesso con username/password a
livello di applicativo, quindi in qualcosa come un file o una tabella
(magari temporanea o solo in memoria) sul database, e controllare
questi dati ad ogni tentativo di accesso. Io terrei in conto anche
altri dati secondari come l'ip del client, il referrer o data/ora.
Più dati tieni più è possibile modificare le politiche di accesso con
facilità man mano che si presentano specifiche necessità nell'ambiente
finale.
Ciao!

Voi che metodo adottereste? A livello concettuale intendo.
Un sistema semplice e' registrare in sessione browser, IP e quant'altro.
Poi verifichi le sessioni aperte e se ci sono collisioni. Nel caso, tiri
giu' una delle due sessioni (si puo' discutere quale sia meglio) e - nel
caso di login con dati diversi - segnali la cosa a video.
Le conseguenze possono essere:
- due utenti con lo stesso nome dallo stesso IP (es. ufficio), risultano
  essere lo stesso utente e ti fregano - ESATTAMENTE COME ORA
- un utente che apra due finestre sul sito dal proprio PC, ma usando due
  browser differenti, si vede non funzionare il secondo
- due utenti con lo stesso nome da IP diversi, il secondo non entra
- due utenti in grado di falsificare il proprio IP (lol) - oltre a tutti
  gli altri dati - ti fregano - ESATTAMENTE COME ORA
- un singolo utente che vada giu' dvro di TOR + Privoxy non riuscira' ad
  accedere proprio.
Leonardo
-- 
And where the black and corkscrew towers climb,
Lost and athirst the ragged pack abides,
Old as the aeons, trapped in tombs of time,
Sailing the tortuous temporal tides

Grazie.

> Poi verifichi le sessioni aperte e se ci sono collisioni.
Scusa... come si fa la verifica delle sessioni aperte? Sempre con
l'appoggio del db?


Si, è il metodo più semplice. In fase di login, come ti hanno già 
suggerito, memorizzi su db (associato all'id della sessione) più dati 
possibili (utente, ip, browser etc...) se la solita credenziale (utente) 
viene utilizzato su un'altra macchina, quest'ultima diventerà la nuova 
connessione dell'utente x, resettando i possibili parametri in sessione.
Ovviamente se coloro che si connettono sono dietro un proxy e hanno 
macchine uguali è un pasticcio!
	Francesco

l'appoggio del db?
Sostanzialmente si': guardi quali sessioni hanno acceduto al sistema nei
precedenti, che so, cinque minuti.
Ormai comunque con AJAX il problema del logout non si pone piu' (certo -
se il client ha Javascript). Metti un applettino AJAX che ogni minuto ti
aggiorna la tabella, appena uno si stacca l'applet smette di aggiornarla
e tu t'accorgi che se n'e' andato. Addirittura puoi misurare esattamente
il tempo che passa su ciascuna pagina (tanto l'applet deve stare su ogni
pagina COMUNQUE, se no non funziona).



Come ti potrebbe mai aiutare tutto questo con il problema degli
accessi?

macchine uguali è un pasticcio!
...per loro :-)
Un sistema semplice quanto stronzo e' tenere in tabella username e
sessionid, che di sicuro e' stato assegnato unico a ogni browser.
	DELETE FROM sessions WHERE sessionid != '$PHPSESSID'
		AND user = '$username';
...se c'e' un utente solo, non succede mai nulla e costa poco.
Ma se ci sono due utenti, inevitabilmente, si cancellano a vicenda
i dati, buttandosi continuamente fuori l'un l'altro ]:-)
Basta scrivere nella pagina di login, dove uno arriva se non trova
i dati in sessions,
	"Dovete avécci i cookie, dovete fa' i bravi,
	 e dovete essere voi soli e no in due o tre..."
...e quando uno arriva al login, ANCORA non ha username, quindi la
cancellazione non c'e', quindi in sessions gli ultimi dati ci sono
e appena fa il login si possono, per una volta sola, recuperare; e
cosi' uno legge
	"Il tuo ultimo login e' stato da qui, in questo modo"
e subito sotto "...e se ci sono problemi verifica che non ci siano
sessioni aperte da altrove, capitto mi hai".


accessi?
Ora che mi ci fai pensare, mi sa che mi sono fatto un trip insensato.
Il sistema per cui ogni sessione cancella tutte le altre dello stesso
utente, di modo che due utenti in collisione si buttano fuori finche'
capiscono come non sia aria, e' ugualmente efficace, e piu' semplice.
Un controllo del tipo che dicevo potrebbe al limite avere senso se si
volesse consentire un massimo di "N" accessi per ciascun utente (cosa
comunque simulabile altrettanto bene usando dei gruppi di utenti), di
modo che mi serve sapere quante copie simultanee dell'utente X sono -
in ogni momento - collegate al sito.
Ma per il caso di "un utente, una sessione di navigazione", non serve
a niente.




Colorito... In ogni caso credo sia una buona idea insultare un proprio
cliente nel caso in cui qualcuno "rubi" o "trovi" il suo username/
password (magari anche proprio per colpa del programmatore che non ha
messo in sicurezza il server come si deve).
Tutte queste soluzioni risolvono una piccola parte del problema
generale, e non prevedono in alcuno modo alcuna flessibilità per
cambiamenti di politica di accesso.
Faccio un esempio banale: se ti accorgi di strane operazioni
sull'utente X accede sempre solo con una sola sessione per volta, ma
una volta dall'Italia e una dall'India, magari ti piacerebbe bloccare
una delle due richieste in base alla localizzazione dell'IP.
Altro esempio: se l'utente Y fa specifica richiesta di poter avere più
sessioni aperte, o necessita di accedere senza supporto javascript
(magari per scaricamento dati con tool come wget) magari vuoi farlo
contento.
Il mio consiglio generale è che il fulcro della situazione non è
perdere tempo con il workflow, che sicuramente cambia di continuo come
cambiano le situazioni in corsa, ma la memorizzazione e l'analisi dei
dati disponibili. Generalizzando questi è possibile scrivere
facilmente funzioni per ogni situazione. Credo questo sia uno dei
pochi casi dove una buona progettazione aiuta a non passare notti
insonni buttando via e riscrivendo kg di codice.

 
Difatti mi sono reso conto di aver scritto una castroneria, visto che 
avevo indicato di memorizzare anche l'id della sessione, univoco per 
ogni browser!
	Francesco

xyzale ha scritto:

se sei root sul server non è un problema..
sposti l'area riservata in una directory /areariservata
poi tramite mod_ssl abiliti il controllo certificati client e fai 
loggare i clienti paganti di smart card o token, meglio se utilizzi 
direttamente
https://www.firma.infocert.it/
così sei certo che non presteranno la propria smart card all'amico fritz 
di turno.
Non devi scrivere cretinate in php ed hai la certezza di chi si logga e 
quando

 Alessio