Newsgroup: it.comp.software.database
Titolo: Soluzione migliore per gestione account sito internet

Salve, uso SQL server 2000 per gestire tutte le informazioni di un
sito internet. Il problema è che non so qual'è la soluzione migliore
per gestire gli account di tutti gli utenti (che possono essere anche
alcune migliaia).
Mi conviene creare una tabella account con i campi, ad es. userid,
pass e ruolo, oppure usare la gestione utenti e ruoli integrata di sql
server?

egisto wrote:

come preferisci. ho notato però che la 1^ versione che hai citato è la 
piu usata.

 piu usata.
...sono di parere diammetralmente opposto. Non vedo perchè mai doversi
reinventare qualcosa che SQL Server fornisce in maniera nativa...
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com
http://italy.mvps.org

 reinventare qualcosa che SQL Server fornisce in maniera nativa...
1. perchè hai sotto controllo quello che fai (il dba potrebbe essere un 
pirla)
2. possibilità di fare gestire insert e delete di utenti direttamente 
agli utenti attraverso interfaccia web
3. sistema piu flessibile e customizato per le tue esigenze

 3. sistema piu flessibile e customizato per le tue esigenze
Perchè?!?



--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 internet o pagine della guida in linea di sql server 2000)
Dai un'occhiata a questo mio articolo pubblicato su TechNet...
http://www.microsoft.com/italy/technet/support/mvp/permessi.asp
Ciao


 alcune migliaia).
ho seguito il 3d, ma a monte non ho capito cosa fanno (o devono poter
fare) questi utenti. Sono utenti che accedono a dati del db oppure sul
db tieni traccia degli utenti che fanno altro?

 Perchè?!?
perchè lo fai tu e lo fai come ti pare.

 perchè lo fai tu e lo fai come ti pare.
...finora non hai ancora accennato ad alcun vantaggio (o possibile
estensione) a questo tipo di approccio, ma hai evidenziato soltanto che
"eventuali problemi" possono essere tracciati dai log (che devi comunque
mettere su e gestire)... ;-)
Ciao


 estensione) a questo tipo di approccio
come no? ma hai letto quello che ho scritto?

yoghurt² wrote:

volevo aggiungere che personalemnte non sono favorevole o contrario a 
uno dei due approcci. ho solo scritto che "ho notato però che la 1^ 
versione che hai citato è la piu usata.".
te invece sebra che vuoi usare a tutti i costi la gestione utenti di sql 
server. come mai? esperienze negative? o semplicemente sei un dba?

 come no? ma hai letto quello che ho scritto?
Si, con la dovuta attenzione... ed anche se qualcosa può essermi sfuggito mi
sembra di aver ribattuto ogni argomentazione esponendoti il mio punto di
vista e le mie ragioni. Per sintetizzarle finora sono emersi due punti: il
primo che il "sistema personalizzato" è più flessibile (opinione tua anche
se non hai ancora indicato perchè); ed il secondo è che questa soluzione è
utilizzabile via web (perchè mai dovrei farlo da web poi me lo spieghi,
spero almeno che la connessione sia protetta... :-) ) ma anche
l'appartenenza ad un ruolo è possibile gestirla per mezzo di comandi T-SQL
quindi non vedo, in questo, alcuna differenza... Per contro la differenza
sussiste qualora la gestione della "security" sia fatta per via applicativa
sulla base di info memorizzate in tabelle. Ho già esposto cosa succede se si
accede ai dati al di fuori dell'applicazione (Access, MSQuery, EM o quello
che vuoi) dove l'assenza di qualunque regola consentirebbe all'utente (a
questo punto anonimo) di fare ciò che vuole... Se non hai altre
argomentazioni/integrazioni/precisazioni/varie ai punti di cui sopra penso
che chiunque possa trarre le sue conclusioni...
Bye


 sql server. come mai? esperienze negative? o semplicemente sei un dba?
Sono un DBA dal 1998 (sono un ex developer) e non vedo alcun vantaggio ad
utilizzare qualcosa di diverso da quanto fornito nativamente e le poche
occasioni in cui erano state implementate soluzioni "alternative" erano
legate ad alcune limitazioni della versione 6.5 primo fra tutti il fatto che
non era consentito ad un utente appartenere a più di un gruppo. Facevo il
developer in quel progetto... ;-)
Non escludo ci siano altrer ragioni che inducano ad applicare questo genere
di soluzioni ma temo che la maggior parte delle volte sia dovuto a non
conoscenza delle feature native... :-(


 Sono un DBA dal 1998 (sono un ex developer) e non vedo alcun vantaggio ad
Scusa se mi inserisco... per curiosita`... come mai sei passato dallo sviluppo
all'"amministrazione" ? Cambio di interessi personali, circostanze o semplice
passione per la teoria dei DB?
-- 
Lawrence


Ma lo sai che Luca con la complicità di Gianluca (Hotz) è riuscito a fare
cambiare "bandiera" anche a me? :-)
Forse "abbiamo aperto gli occhi" oppure semplicemente abbiamo messo in
dubbio la nostra "onnipotenza" come dev? :-D
Ciao!
-- 
Lorenzo Benaglia



Per un'applicazione web la seconda soluzione è semplicemente folle. Ti 
segheresti via ogni possibilità di porting su backend diversi e  di 
connection pooling, per non parlare dei problemi di sicurezza...
-- 
Fabrizio "Hermooz" Ermini

 circostanze o semplice passione per la teoria dei DB?
Un po tutte queste cose che hai detto ed inoltre aggiungo una frase che ho
riportato nella mia biografia sul sito degli MVP italiani (per chi non
avesse nulla da fare è il link riportato in fondo alla mia firma... :-) )
===================
In precedenza la mia attività era quella di sviluppatore, ma quando mi sono
accorto che i bug delle mie applicazioni erano più delle routine funzionanti
ho deciso che forse era il caso di cambiare attività.
===================
Ciao...


 dubbio la nostra "onnipotenza" come dev? :-D
Eh eh io sono tutt'altro che onnipotente ma recentemente (faccio il dev
veramente da poco tempo ;-)) ho scoperto un interesse per l'ingegneria
del software maggiore per quello che ho per la terza forma normale :P
Chissa` magari... in futuro... ;-)
-- 
Lawrence

[SNIPPONE]
LB> Ma lo sai che Luca con la complicità di Gianluca (Hotz) è
LB> riuscito a fare cambiare "bandiera" anche a me? :-)
Prima di dire simili eresie ti devo interrogare
sul Third Manifesto ;-)
Gianluca.



La gestione utenti si riferisce, io credo, agli utenti di SQL server.
In questo caso, parlando del sito, l'utente e' uno solo: quello che ha
accesso alle varie tabelle. Volendo essere piu' sicuri, due utenti - e
cioe' quello associato ad ASP/PHP/Webserver, che ad alcune tabelle per
esempio puo' accedere a sola lettura, e quello associato alla gestione
che puo' fare tutto -- sulle sole tabelle relative al sito.
Poi ci sono gli utenti _del sito_ dei quali meno SQL server sa, meglio
e' (IMHO). Per questi userei una tabella account come dici tu.
Leonardo
-- 
Nach doiligh domhsa mo chailin a mholadh
'S ni he amhain mar bhi si or
Bhi si mar gath greine a dhul in eadan na gloinne
Is bhi sceimh mhna na finne le mo cailin or

 accesso alle varie tabelle.
Io per utenti intendo i singoli utenti che, per esempio, si iscrivono al
sito.
Nel caso specifico, io ho due tipi di utenti che si possono registrare al
sito: responsabile e utente generico.
Io ho creato due ruoli (all'interno di SQL server), e ogni utente che si
registra diventa utente di SQL server e appartiene al ruolo che gli compete.
Un dubbio che mi viene usando questa tecnica è il seguente: se volessi
trasferire il database su un altro dbms (sempre sql server), come faccio a
trasferire gli utenti sull'altro bdms? Ad esempio se un utente presente sul
nuovo dbms ha lo stesso nome di login.


sito.
Appunto. Questi utenti non hanno nemmeno necessita' di sapere che esiste
SQL Server, ne' dovrebbero poter fare niente su SQL Server. Sara' invece
il webserver che assumendo il ruolo di admin o user, andra' a recuperare
i dati necessari nelle varie tabelle.
Mettere gli "utenti del sito" come "utenti SQL server" non ha senso (per
questo scenario, e IMHO). Tanto varrebbe, su Unix, creare una utenza con
home, eccetera, per ogni utente del sito, oppure inviare una copia delle
chiavi della sede della Telecom a ogni utente dell'elenco telefonico.
Puo' essere che si semplifichino le operazioni di login (boh!), ma tutto
il resto diventa inutilmente complicato, oltre a non essere portabile su
altri DBMS, e poco estendibile.


 sito.
x me allora è una tabella su qualunque DB ti vena in mente