Gestione utenti registrati

lunedì 09 aprile 2007 - 00.26

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

squilibrio Profilo | Expert

527 messaggi | Data Invio: lun 9 apr 2007 - 00:26

Ciao a tutti, ho realizzato un form di registrazione da parte dell'utente, a questo punto vorrei gestire nel modo corretto l'operazione di login ... voi come gestite la fase di login dell'utente e come memorizzato lo stato di "logged" (in tutte le pagine del sito) da parte dell'utente... e il codice/nome utente dove conviene memorizzarlo??? (sessione, cookies... altro??)

PS: non voglio usare il sistema di autenticazione di .NET 2.0

Grazie per l'aiuto

Gianluca_Sharper Profilo | Newbie

37 messaggi | Data Invio: mar 10 apr 2007 - 11:09

ciao squilibrio

io solitamente faccio una struct con i dati dell'utente una volta che si e' loggato, me li metto in sessione e me li porto dietro finche' non chiude la finestra oppure non preme il tasto logout.

esempio
--------------------------
public struct User
{
public string UserName;
public string Name;
}

User myuser = new User();
myuser.UserName = prendi lo username dal db
myuser.Name = prendi il nome dal db

Session["UserSession"] = myuser
-------------------------------

quando poi hai bisogno di usare un dato dell'utente basta che tiri fuori i dati dalla sesisone
User myuser =(User)Session["UserSession"];

e poi chesso
Label1.Text= "Benvenuto"+myuser.UserName;

spero di esserti stato di aiuto

ciao!

Gianluca

Le cose impossibili diventano possibili solo quando uno non sa che erano considerate impossibli

trasportation Profilo | Junior Member

104 messaggi | Data Invio: mar 10 apr 2007 - 16:00

Mi dispiace per Gianluca

, ma la gestione dell'utente in questo modo (cioè con le sessioni) è terribile, perchè non vuoi usare il sistema di autenticazione di 2.0?

Il metodo di autenticazione di 2.0 è ottimo e fatto benissimo, diverso è se non vuoi usare il suo database (che è pessimo) ma puoi tranquillamente utilizzare un tuo storage dei dati la sola cosa che devi fare è crearti un provider.

Le sessioni facilitano la vita, ci sono, ma non per questo vanno usate, sono una di quelle brutte cose che si è portata dietro da asp 3.0 e la gente continua ad utilizzarla perchè non capisce che c'è di meglio.

Se devi fare una cosa falla bene.

/*
* web: http://www.robertobeccari.it
*/

Gianluca_Sharper Profilo | Newbie

37 messaggi | Data Invio: mar 10 apr 2007 - 16:20

Spiegati meglio non ho letto molte soluzioni dalla tua risposta
se c'e' da imparare nuove cose ben venga ma non vedo il perche' non utilizzare sessioni dato che riescono a mantenerti lo stato in modalità cookieless.
Ti prego poi di spiegare il perche' e' una cosa terribile l'utilizzo di sessioni questo mi incuriosisce

ciao

Gianluca

Le cose impossibili diventano possibili solo quando uno non sa che erano considerate impossibli

trasportation Profilo | Junior Member

104 messaggi | Data Invio: mar 10 apr 2007 - 17:32

Le sessioni sono rappresentate da un contenitore in memoria che può contenere di tutto e di +, questo porta una caduta di performance della macchina server perchè tutto ciò che viene messo dentro a questo contenitore viene matenuto per ogni utente.
Pensa ad una condizione nella quale ogni utente possiede una struttura come quello che tu hai definito e la mantiene in memoria, se ci sono 2 utenti la cosa funziona ma se ce ne sono 200 la cosa già non funziona più perchè tutte le informazioni sono in memoria del server in più ogni volta che le usi fare un cast del dato perchè la sessione è un oggetto generico.

Tu utilizzi la modalità cookieless? se è così puoi gestire il ticket dell'utente nello stesso modo in cui lo fà asp.net per le sessioni visto che il session id è presente nell'url delle chiamate, altrimenti utilizza i cookie per appoggiare il ticket sul client.

Il fatto di non utilizzarle diventa una best practice per tutti i tuoi progetti sia piccoli che grandi, se sbagli già su quelli piccoli su progetti medio/grandi saranno sbagli maggiori

.

Il mio post dava già la soluzione, diceva di utilizzare l'autenticazione di asp.net grazie al suo ticket di autenticazione puoi risalire all'utente connesso in qualsiasi momento.

Altri modi per matenere informazioni per la sessione di lavoro (non è la sessione di asp.net) è quello di utilizzare viewstate come storage e context.items per la transizione delle informazioni tra le varie pagine, questo ovviamente dipende come è fato il tuo sito.

Se vuoi proprio utilizzare le sessioni, ti consiglio di metterci dentro meno roba possibile es. solo il login id dell'utente e recuperare ogni volta che ti serve il suo nome, cognome, ecc da uno storage (sql, mysql, ecc.).

Questo link ti dà una serie di spunti su come ottimizzare il carico sul server e parla anche delle sessioni
http://www.aspitalia.com/articoli/ottimizza.aspx

Se vuoi ho anche un sacco di altri link che dicono di disabilitare le variabili di seesione.

Spero di aver chiarito meglio.

Ciao

R.
/*
* web: http://www.robertobeccari.it
*/

Gianluca_Sharper Profilo | Newbie

37 messaggi | Data Invio: mar 10 apr 2007 - 17:52

Uhm.. dovrei allora vedermi questo sistema di autenticazione.
Comunque ho sempre utilizzato sessioni fino a giusto mezzo minuto fa

e non ho mai avuto problemi anche nel caso in cui ci sono molti utenti collegati anche piu' dei 200.
Se pero' la tua strada migliora le prestazioni allora provo a darci un'occhiata anche perche' comunque la cosa potra venirmi d'aiuto in altre applicazioni spero.
Grazie comunque per le info, io ho solo detto in maniera compatta un metodo che uso io per portarmi dietro un utente durante la sua sessione di lavoro senza usare l'autenticazione di asp.net come chiedeva squilibrio. Il resto e' tutta una lezione

Ciao

Gianluca

Le cose impossibili diventano possibili solo quando uno non sa che erano considerate impossibli

trasportation Profilo | Junior Member

104 messaggi | Data Invio: mer 11 apr 2007 - 07:39

Un'ultima nota...

Se capisci bene il sistema di autenticazione di asp.net 2.0, ti porterà solo vantaggi, te ne dico 2 ma ce ne sono molti altri:

1) creandoti un tuo sistema custom di autenticazione basato sui proivider potrai applicarlo anche ad altre applicazioni non scritte da te o integrare la tua security con tutte quelle applicazioni che si basano su autenticazione form (forum open source, blog, ecc.).

2) Potrai utilizzare tutti gli oggettii asp.net 2.0 come il login, stato utente connesso, ecc. senza scrivere una riga di codice.

Io lo utilizzo da un sacco (ho scritto un mio provider per diversi motivi) ma fino ad oggi ho visto solo vantaggi a lungo termine per la semplicità di integrazione della mia autenticazione con altre applicazioni o comunque con applicazioni asp.net scritte al volo per demo.

R.
/*
* web: http://www.robertobeccari.it
*/

nullatore Profilo | Junior Member

191 messaggi | Data Invio: ven 13 apr 2007 - 21:55

In un manuale C#.net della microsoftpress trovo scritto che per strutture grosse ( quanto?) è sconsigliato utilizzare la ViewState bensi la Session, tant'e' che tra i vari Postback di una pagina conservo in Session un dataset di interesse con il quale popolo una gridview (ovviamente per evitare una query ogni postback).

Come mi devo comportare alla luce di quanto detto prima?
Le performance sono intaccate maggiormente da una session pesante, da un viewstate pesante o da una query pesante?

trasportation Profilo | Junior Member

104 messaggi | Data Invio: lun 16 apr 2007 - 07:51

Purtroppo è verissimo, Microsoft spesso e volentieri nei suoi esempio utilizza le session un pò per ogni cosa ma sono cose da utilizzare con parsimonia.

Ti posso dire la mia a riguardo.

- Le session appesantiscono la parte server quindi più utenti ci sono più il server fà fatica
- Il view state appesantisce la pagina quindi la pagina è più lenta a durante il download ma questo vale per il songolo utente non per il server
- La query è la cosa che preferisco perchè ado.net ha dei sistemi di caching che utilizza per ottimizzare le query e le connessioni, se parliamo di SQL o DB del genere (non DB Access ovviamente), quindi la stessa query ripetura più volte è più veloce della stessa query ripetuta una sola volta nei tempi di risposta.

Purtroppo non c'è una strada che vale sempre e comunque, ma conoscendo un pò come funzionano questi oggetti puoi fare un modo che il tutto sia più performante.

R.

/*
* web: http://www.robertobeccari.it
*/

squilibrio Profilo | Expert

527 messaggi | Data Invio: ven 20 apr 2007 - 16:31

Personalmente odio il sistema di autenticazione di 2.0

E' incredibile che in fase di sviluppo sia disponibile l'utility di amminsitrazione e che invece in produzione non ci sia..... come è possibile gestire gli utenti/permess, una volta che il sistema va in produzione??

Ritornando al problema iniziale: qualcuno potrebbe darmi indicazioni sulle strade alternative per gestire l'autenticazione di utenti?

Grazie

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !