Providers Membership,Roles Personalizzati PER FORZA

lunedì 15 gennaio 2007 - 17.50

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

nullatore Profilo | Junior Member

191 messaggi | Data Invio: lun 15 gen 2007 - 17:50

Dopo aver scoperto che quei 'mattacchoni' della Microsoft ('ci loro) hanno compilato le dll del SqlMembership provider facendo rifermento per ogni oggetto del DB a DBO.xxxxxx e non avendo trovato soluzioni mi trovo costretto a creare un provider personalizzato delle appartenenza (e forse anche dei ruoli).

E da qui mille domande...

1) dove posso trovare tutorial o del codice da studiare?

2) utilizzando un provider custom posso usare un DB dove non ci sia presente neanche una delle carte/viste/sp aspnet_xxxxx?

3) creando un provider custom devo fare l'override anche della classe FormsAuthentication?

4) Mettiamo che all' Onclick di un bottone ci sia questo codice:

public void Login_OnClick(object sender, EventArgs args)
{
if (Membership.ValidateUser(UsernameTextbox.Text, PasswordTextbox.Text))
FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, false);
}

Mettiamoci nel caso non abbia ancora customizzato nulla (utilizzo membership del 2.0).
La creazione del cookie che memorizza le informazioni sull' appartenza e i ruoli è dentro il metodo ValidateUser? Se sì, chi mi dice come ricrearla nel caso di customizzazione?

nullatore Profilo | Junior Member

191 messaggi | Data Invio: mer 17 gen 2007 - 00:43

forse per colpa dalla foga (e dal nervosismo) non sono stato chiaro nelle mie richieste.

2 domande cruciali:

1) customizzando la membership devo customizzare anche i roles?

2) dentro il metodo FormsAuthentication.RedirectFromLoginPage viene richiamato qualche metodo della classe Roles?

nullatore Profilo | Junior Member

191 messaggi | Data Invio: ven 19 gen 2007 - 02:14

>>2) dentro il metodo FormsAuthentication.RedirectFromLoginPage
>>viene richiamato qualche metodo della classe Roles?
>No

Perdonami allora non mi è chiaro il meccanisco.

Mettiamo che abbia customizzato la membership, e il mio ValidateUser sia composto solo da un RETURN TRUE (è assurdo ma è per capirci e da quello che ho capito nessuno me lo vieta).

Mettiamo anche che venga eseguito questo codice all'atto di invio delle mie credenziali ( da un tipo pannello di autenticazione, con login e password, alla pressione del bottone di LOG-IN):

If ([lamiaclassemembership].ValidateUser(login.Text,password.Text)
FormAuthentication.RedirectFromLoginPage(login.Text,false)

Questo codice mi catapulta in una zona del portale che prima non era accessibile perche' bloccati dal web.config, in cui c'e' un <deny users="?" />.

Tutto questo presumendo che il RedirectFromLoginPage crei il cookie o ticket (che tra l'altro non ho capito la differenza tra i 2) che fungerà da "lasciapassare" per il DENY che blocca l'area interna.

A ritroso faccio questo ragionamento: Un DENY ROLES="ospiti" scritto nel web.config si oppone all'ingresso finchè non viene trovato un cookie o ticket in cui sia riportato il ruolo dell'utente e che questo sia diverso da 'OSPITI'. Ma questo cookie chi lo genera? (Da qui la domanda se RedirectFromLoginPage chiamasse Roles creare il ticket)

Insomma qual'e' il ciclo di funzionamento dell'architettura 'autenticazione2.0"?

nullatore Profilo | Junior Member

191 messaggi | Data Invio: ven 19 gen 2007 - 14:42

>Il discorso è piuttosto lungo ma cerco di farlo semplice e breve.
>Per l'autenticazione e in generale per la profilazione degli
>utenti in asp.net sia con 1.1 che con 2.0 hai due possibilità
>o l'autenticazione tramite utente o tramite ruolo.
>Ora con la versione 2.0 sono state aggiunte delle API sia per
>la Membership che per i ruoli, dove tu tramite una gestione a
>Provider puoi gestire questi oggetti.
>Ci sono dei provider di default oppure puoi crearti tu un tuo
>provider.
>Quando usi l'autenticazione tramite form quando l'utente inserisce
>le sue credenziali viene creato un ticket che volendo si può
>salvare su un cookie(ma non è per forza così) e tramite questo
>ticket, il processo asp.net riconosce se l'utente ha diritti
>per accedere alla risorsa richiesta.
>
>Sono stato abbastanza chiaro?

Il tuo discorso NUNFA' NA PIEGA (come dicono dalle parte mie).

Ma mantiene in piedi la mia domanda. Ora te la riformulo in un altro modo.

Ho configurato la mia webapplication per utilizzare la membership e i roles cosi come dati da MAMMA Microsoft utilizzando come provider quelli 'Sql'.
Ho aggiunto nel mio web.config, tra i vari DENY che bloccanno la visione di alcune pagine ai non autenticati, anche dei DENY che bloccano alcuni ruoli.

Nel mio pannellino di login, alla pressione del tasto di LOG-IN, viene semplicemente eseguito tale codice:
If (Membership.ValidateUser(login.Text,password.Text))
FormAuthentication.RedirectFromLoginPage(login.Text,false)

Il tutto funziona perfettamente (ahimè solo in locale, poiche quegli eunuchi della MS hanno compilato le classi membership referenziando gli oggetti del DB con il suffisso "dbo"...e io su aruba il dbo me lo sbatto sui denti).

ORA MI CHIEDO: supponendo che ValidateUser si limiti a vedere se esiste l'utente e se ha digitato la password giusta (cosa che farebbe tra l'altro l'ovverride di tale metodo nella mia custom-membership) e apprendendo dalle tue risposte che il metodo FormAuthentication.RedirectFromLoginPage non faccia riferimento direttamente o indirettamente alla classe Roles, ma solamente catapulti l'utente dove è giusto che vada (nella pagina configuarata come 'DefaultUrl'),
mi chiedo come sia possibile per il web.config limitare l'ingresso ad alcuni ruoli! Dove sta il codice che ha preso l'utente che si è loggato, l'abbia risolto in termini di ruolo e abbia creato il ticket per i rouli (che sara poi la discrimante per il web.config per l'accesso ad alcune risorse)??

Spero di esser stato io chiaro. E grazie tanto per la pazienza portata.

nullatore Profilo | Junior Member

191 messaggi | Data Invio: mar 23 gen 2007 - 13:29

>Ma una cosa ma i ruoli nel web.config li hai abilitati?
>Per l'accesso alle pagine dipende nel location path cosa hai
>inserito, come ti dicevo puoi decidere se scegliere utenti o
>ruoli o tutti e due.
>Ora se hai inserito i ruoli per negare l'accesso se non abiliti
>i ruoli non credo che riesci a gestire la cosa.

I ruoli sono stati abilitati. Ma credo d'aver capito come funziona il tutto. Credo di non sbagliare se dico che quando viene chiamato il metodo RedirectFromLoginPage al quale si passa il nome dell'utente, viene chiamato un metodo della classe Roles (ovviamente se è stata abilitata nel web.config) per risolvere dal nome dell'utente il suo ruolo e confezionare un ticket adeguato.

Sbaglio?

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 !