161 messaggi dal 07 settembre 2009
Lo leggerò senz'altro =)

Ora ho solo una domanda, all'interno di un cookie posso inserire tutte le informazioni che desidero? ho letto su uno degli articoli la soluzione di separare le informazioni con un ":" per poi recuperarle, ma mi chiedevo se erano disponibili soluzioni alternative o meno

Grazie ancora.


Davide
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao Davide,

doppiomango ha scritto:

Ora ho solo una domanda, all'interno di un cookie posso inserire tutte le informazioni che desidero?

Sì, anche se ogni cookie ha un limite di 4kb. Considera che ogni cookie che scrivi viene reinviato al server come parte di ogni successiva richiesta web, quindi non è consigliabile inserirvi troppe informazioni. Che tipo di dati vuoi inserire, in particolare?

doppiomango ha scritto:

separare le informazioni con un ":" per poi recuperarle

Lato server non devi usare accorgimenti particolari. Per scrivere un cookie disponi di una collezione Response.Cookies che è abbastanza semplice da usare. Si occuperà lei di usare i giusti caratteri separatori, tu devi solo definire il nome del cookie e assegnargli un valore, eventualmente valorizzando anche le sue chiavi.
Qui c'è un articolo di Daniele che ti mostra come scrivere i cookies.
http://www.aspitalia.com/script/355/Cookies-ASP.NET.aspx

Il contenuto di un cookie creato da Asp.Net riuscirai a leggerlo anche col javascript, ammesso che non sia del tipo HttpOnly (quello creato dalla FormsAuthentication lo è).
Se usi jQuery, esiste un plugin che rende la loro lettura e scrittura molto semplice. Anche in questo caso non dovrai preoccuparti di quali caratteri separatori usare.
https://github.com/carhartl/jquery-cookie

ciao
Modificato da BrightSoul il 24 maggio 2013 00.41 -

Enjoy learning and just keep making
161 messaggi dal 07 settembre 2009
Nel cookie mi servono varie informazioni come l'id utente, il nome, e alcune specifiche dell'amministrazione (ad esempio quali campi far vedere e quali no).

All'inizio pensavo di tenere le informazioni in una o più sessioni evitando di richiamare il database 20 volte solo per ricevere sempre le stesse informazioni.

Anche se leggendo quello che mi hai scritto capisco meglio sia il funzionamento del FormsAuthentication che dei cookies in generale.

In più ho letto la parte riguardo i browser con i cookies disabilitati e facendo una prova l'url sembra corretto (www.xxxx.it/codice/pagina.aspx), ma mi ritorna "The system cannot find the file specified."
Bisogna aggiungere un controllo di qualche tipo per far riconoscere la pagina? o stò sbagliando qualcosa?
Il web.config è abbastanza semplice e lineare, mi sembra improbabile che sia li il problema.
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" timeout="40320" cookieless="AutoDetect" defaultUrl="default.aspx" />
    </authentication>


Con questo sistema, la gestione dei cookies nel sito cambia nel caso in cui si usi un browser che non lo supporti? O in quel caso il codice nell'url fa funzionare il tutto ugualmente?

Come sempre grazie per la pazienza =)
Sei sempre di grande aiuto.


Davide
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao!
ok, il problema che si è presentato all'inizio era quello di sessioni che scadono troppo di frequente. L'aver creato un cookie persistente grazie alla FormsAuthentication ci ha concesso di mantenere l'utente collegato per molto più tempo, anche dopo il riavvio del PC.

Ora affrontiamo un nuovo problema, anzi due.

doppiomango ha scritto:

tenere le informazioni in una o più sessioni evitando di richiamare il database 20 volte
...
Nel cookie mi servono varie informazioni come l'id utente, il nome, e alcune specifiche dell'amministrazione (ad esempio quali campi far vedere e quali no).

Il primo problema consiste nel numero di query di inviare al database. Vogliamo che questo numero sia basso quindi per risolverlo bisogna usare un meccanismo di caching come la sessione, i cookies o la cache di Asp.NET.

L'altro problema è legato alla confidenzialità dei dati da cachare. Non possiamo consentire che i privilegi assegnati all'utente (cioè i criteri che gli consentono di vedere o no alcuni campi), vengano memorizzati lato client. Dobbiamo tenerli al sicuro nel server perché se glieli inserissimo in charo in un cookie, lui potrebbe modificarli a piacimento e conferirsi privilegi che non gli spettano.

Cacharli in sessione era una buona scelta, perhé quei dati restano confinati nella memoria RAM del server e l'utente non ha possibilità di modificarli.
A questo punto non ha importanza se la Sessione scade spesso perché, se anche dovesse scadere, tu puoi sempre recuperare di nuovo di dati dal database e ri-cacharli subito in sessione.
//ottengo il nome dell'utente che in precedenza avevo cachato in sessione
var nome = Session["nome"];
//se il nome non era più in sessione...
if (nome == null){
  //allora lo recupero dal database
  nome = OttieniNomeUtenteDalDb();
  //e lo rimetto in cache
  Session["nome"] = nome;
}
Response.Write("Nome: " + nome);


doppiomango ha scritto:

In più ho letto la parte riguardo i browser con i cookies disabilitati e facendo una prova l'url sembra corretto (www.xxxx.it/codice/pagina.aspx), ma mi ritorna "The system cannot find the file specified."

Mmh, non so a quale "file" l'errore faccia riferimento. Nella pagina di errori vedi lo stack strace, con evidenziata la riga di codice che sta causando il problema? Se dipendesse dal fatto che pagina.aspx non viene trovata, semplicemente avresti un errore 404.
Quando l'utente ha i cookies disabilitati, al massimo non riuscirà a restare loggato al sito. Comunque tu hai impostato la modalità cookieless="AutoDetect" e quindi l'autenticazione funzionerà anche per lui (verrà inserito un codice lunghissimo nell'URL, che potrebbe causarti problemi con i percorsi lato client, ad esempio a .js e css).

doppiomango ha scritto:

Nel cookie mi servono varie informazioni come l'id utente, il nome, e alcune specifiche dell'amministrazione (ad esempio quali campi far vedere e quali no).

L'id utente non ti serve, puoi recuperarlo lato server da User.Identity.Name dopo aver loggato l'utente.

Per il nome e le specifiche puoi cacharle nella sessione, come vedevamo prima, altrimenti ci sono delle API di Asp.Net che puoi usare proprio a questo scopo.

La Profile API ti consente di accedere ad informazioni accessorie dell'utente, come il Nome e altri dati anagrafici o preferenze varie.

Con la Roles API puoi gestire i suoi ruoli, che ti consentiranno di capire se può accedere a determinate sezioni del sito, oppure se deve vedere o meno alcuni campi. I ruoli possono essere cachati su cookie in maniera crittograta, quindi le interrogazioni al db saranno ridotte al minimo.

ciao

Enjoy learning and just keep making
161 messaggi dal 07 settembre 2009
Usare Session e cookie contemporaneamente è un'idea che non mi era ancora venuta in mente ma che trovo molto interessante e che mi risolve il problema delle sessioni che scadono e della sicurezza dei dati.

BrightSoul ha scritto:
L'altro problema è legato alla confidenzialità dei dati da cachare. Non possiamo consentire che i privilegi assegnati all'utente (cioè i criteri che gli consentono di vedere o no alcuni campi), vengano memorizzati lato client.

Ma il problema non si pone anche mettendo il livello di accesso (Admin,Utente,...) nel cookie con il FormsAuthentication?



BrightSoul ha scritto:
Mmh, non so a quale "file" l'errore faccia riferimento. Nella pagina di errori vedi lo stack strace, con evidenziata la riga di codice che sta causando il problema? Se dipendesse dal fatto che pagina.aspx non viene trovata, semplicemente avresti un errore 404.
Quando l'utente ha i cookies disabilitati, al massimo non riuscirà a restare loggato al sito. Comunque tu hai impostato la modalità cookieless="AutoDetect" e quindi l'autenticazione funzionerà anche per lui (verrà inserito un codice lunghissimo nell'URL, che potrebbe causarti problemi con i percorsi lato client, ad esempio a .js e css).

Esatto, con quella modalità avrei dovuto dare la possibilità a tutti di potersi loggare al sito ma nell'url, dopo il login, mi appare questo
http://mioindirizzo.it/(X(1))/pagina.aspx?AspxAutoDetectCookieSupport=1
senza il codice lungo che mostra il tutorial e senza errori nello stack trace.


Come sempre grazie per l'aiuto e i preziosi consigli.


Davide
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao Davide,

doppiomango ha scritto:

Ma il problema non si pone anche mettendo il livello di accesso (Admin,Utente,...) nel cookie con il FormsAuthentication?

Il contenuto del cookie che la Roles API scrive è crittografato proprio come quello della FormsAuthetication. Di conseguenza, dell'aspetto della sicurezza se ne occupa ASP.NET. L'utente, se anche provasse a manomettere il cookie, otterrebbe come unico risultato quello di invalidarlo.
Il vantaggio è che, se anche si dovesse scoprire un bug nel sistema di crittografia, lo sistemeresti semplicemente installando gli aggiornamenti da Windows Update per il tuo server.

Sicuramente anche io potrei crittografare i dati con un mi algoritmo e poi inviarli al cookie - sarebbe di certo meglio che inviarli in chiaro - resterebbe comunque un sistema fragile. Se ci fossero dei bug, potrei non accorgermene e comunque starei perdendo tempo nel riscrivere una funzionalità che già esiste in ASP.NET.

doppiomango ha scritto:

senza il codice lungo che mostra il tutorial e senza errori nello stack trace.

Ok, allora fai così: per autenticare l'utente usa FormsAuthentication.RedirectFromLoginPage. Questo metodo accetta gli stessi parametri di SetAuthCookie, e funziona esattamente alla stessa maniera ma in più effettua la ridirezione verso la pagina del sito a cui si era tentato di accedere. A quel punto L'url dovrebbe includere anche il famoso codice che ora non vedi.

ciao

Enjoy learning and just keep making
161 messaggi dal 07 settembre 2009
BrightSoul ha scritto:
Ok, allora fai così: per autenticare l'utente usa FormsAuthentication.RedirectFromLoginPage. Questo metodo accetta gli stessi parametri di SetAuthCookie, e funziona esattamente alla stessa maniera ma in più effettua la ridirezione verso la pagina del sito a cui si era tentato di accedere. A quel punto L'url dovrebbe includere anche il famoso codice che ora non vedi.
ciao

Io uso già FormsAuthentication.RedirectFromLoginPage che mi ritorna l'url "sbagliato".


Poi mi chiedevo... come posso attribuire un array di permessi ad un utente? Diciamo che ho 3 pagine a cui posso accedere solo se ho un determinato tipo di accesso per ognuna di esse non dipendenti l'uno dall'altro. Quindi per la pagina 1 devo avere un'autorizzazione di tipo A, per la pagina 2 di tipo B e di tipo C per la pagina 3 e se voglio entrare in tutte e 3 le pagine mi servono tutte e 3 le autorizzazioni.

Sempre grazie di tutto.


Davide
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao, prego, ora mi sono appassionato al "caso", dobbiamo riuscire a risolverlo :D

doppiomango ha scritto:

Io uso già FormsAuthentication.RedirectFromLoginPage che mi ritorna l'url "sbagliato".

...però non riesco a riprodurre il problema. Può darsi che ASP.NET non abbia avuto modo di svolgere tutti i passi dell'algoritmo di autorilevamento.
Lo trovi spiegato qui, ma non è che ti dia informazioni su come risolvere il problema.
http://msdn.microsoft.com/en-us/library/aa479315.aspx
Prova a fare così: metti il modulo di login in un'apposita pagina, ad esempio login.aspx.
Ora visita l'homepage da utente anonimo, con un browser con i cookies disabilitati. Dovresti essere reindirizzato subito verso /login.aspx?AspxAutoDetectCookieSupport=1. Ora digita i dati di accesso e clicca il Button "Accedi" che causerà il postback di pagina. Poi chiama RedirectFromLoginPage e grazie ad esso dovresti essere in grado di accedere al sito normalmente. Nell'URL noterai il codice lungo anziché (X(1)).
In questo modo, l'iniziale ridirezione alla pagina di login e il successivo postback causato dal bottone dovrebbero essere sufficienti a completare l'autorilevamento.

doppiomango ha scritto:

come posso attribuire un array di permessi ad un utente?

Ti consiglio di usare la Roles API, che ha anche quel meccanismo di caching dei ruoli di cui abbiamo parlato.
Qui trovi un articolo che ti spiega come fare. Sarà molto semplice.
http://www.technade.com/2011/03/how-to-write-your-custom-role-provider.html
Cioè si tratta di crearsi una classe chiamata ad esempio CustomRoleProvider che deriva da RoleProvider.
RoleProvider è una classe astratta che ti chiede di implementare almeno una dozzina di membri (puoi farlo così da Visual Studio). Tuttavia, vai a personalizzare soltanto GetRolesForUser come indicato nell'articolo. Questo metodo che fa proprio quello che chiedevi: restituire un array di ruoli per un dato utente. Ecco infatti la firma del metodo.
public override string[] GetRolesForUser(string username) 

Questo metodo verrà chiamato da ASP.NET durante la fase di creazione dell'identità dell'utente. Nel suo corpo andrai ad interrogare il database e, in base allo username, restituire l'array di stringhe che contiene i nomi dei suoi ruoli.

Poi, per l'accesso alla pagina puoi fare come vedi nell'articolo oppure agire dal web.config. Qui trovi spiegato come fare, in particolare guarda il paragrafo "Allow only users in particular Role".
http://weblogs.asp.net/gurusarkar/archive/2008/09/29/setting-authorization-rules-for-a-particular-page-or-folder-in-web-config.aspx

ciao!
Modificato da BrightSoul il 28 maggio 2013 21.37 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.