31 messaggi dal 04 novembre 2004
 buongiorno..

ho un problema,
Ho effettuato una login Customizzata con l' oggetto asp:login,
nell' Evento Authenticate ho effettuato il mio controllo nel Db,
verificando l'autenticazione dell' utente...

ora vorrei sfruttare le roles integrate per bloccare l'accesso a determinate directory del sito consentendo l'accesso a chi possiede la roles.

ho quindi creato un utente generico "pippo" tramite tool di amministrazione,
poi nel codice metto:
 protected void Login1_Authenticate(object sender, AuthenticateEventArgs e)
{
//Controllo la login nel DB preesistente 
/*
..
*/
e.Autenticated=true;
FormsAuthentication.RedirectFromLoginPage("pippo", true);
}

il problema e che vengo comunque rediretto alla pagina di login.
poichè non mi riconosce l'utente pippo..

come faccio a fargli credere di essere pippo??
31 messaggi dal 04 novembre 2004
ho notato che
bool gotIt =FormsAuthentication.Authenticate("pippo","passPippo$");

mi ritorna false... anche se passPippo$ e' la password effettiva...
mentre
bool existIt = Membership.ValidateUser("pippo","passPippo$");

ritorna True ...

c'e' qualcosa che non mi torna...
31 messaggi dal 04 novembre 2004
ok, praticamente bastava usare l'evento LoginButton_Click anziche'
Login1_Authenticate ,
posto il codice per chi avesse bisogno in seguito:
 protected void LoginButton_Click(object sender, EventArgs e)
    {
      
        string pwd = Login1.Password.Trim();
        string usr = Login1.UserName.Trim();

     
        if (pwd != "")
        {
            bool auth= AUTH.logged(usr, pwd);
            //AUTH.logged torna true se la login e' andata a buon fine
            
            if(auth)
            {

    //Salvo nella Session il vero UserName e la Password 
                Session["login"] = usr;
                Session["password"] = pwd;
               
                //Uso la login generica per avere la Roles giusta.
                if(Membership.ValidateUser("pippo", "passwordpippo$"))
                  FormsAuthentication.RedirectFromLoginPage("pippo", Login1.RememberMeSet);
            }
        }
        
    }

Modificato da kentaromiura il 01 giugno 2006 13.25 -
kentaromiura wrote:
c'e' qualcosa che non mi torna... !]

forse tutto il Provider Model.
il metoto Authenticate di FormsAutentication controlla le credenziali nel web.config, quello di Membership lo fa sfruttando il Membership Provider che hai impostato, quindi probabilmente dentro una tabella di SQL Server. e cmq, mi vengono i brividi a vedere un codice come quello che hai postato, non riesco a capire a cosa servirebbe utilizzare quelle variabili session, in quel modo, per giunta usando username e password fisse per tutti gli utenti...

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
31 messaggi dal 04 novembre 2004
Daniele Bochicchio ha scritto:

forse tutto il Provider Model.

eh, son appena passato a 2.0 ..

il metoto Authenticate di FormsAutentication controlla le credenziali nel web.config, quello di Membership lo fa sfruttando il Membership Provider che hai impostato, quindi probabilmente dentro una tabella di SQL Server.

il codice si basava su esempi reperiti nella rete, dove appunto non veniva specificato questo.. grazie della puntualizzazione.

e cmq, mi vengono i brividi a vedere un codice come quello che hai postato, non riesco a capire a cosa servirebbe utilizzare quelle variabili session, in quel modo, per giunta usando username e password fisse per tutti gli utenti...

no, calma e gesso..
io l'autenticazione la faccio per mezzo di un DB centralizzato esistente
appunto quel AUTH.logged serve a interpellare il db,
volevo solo sfruttare la possibilità di mostrare una parte del sito
solo ad una certa schiera di utenti(appunto quelli con lo stesso ruolo)
mettendo all'interno di una subdirectory il seguente web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.web>
        <authorization>
            <allow roles="pippo" />
            <deny users="*" />
            <deny users="?" />
        </authorization>
    </system.web>
</configuration>

in tal modo naturalmente gli utenti non loggati vedono comunque una parte di sito, e modificando leggermente la login (o mettendone un altra in un area diversa)
posso gestire la parte di amministrazione ecc..
la session serve per avere il vero username e la vera password usata,
visto che utilizzando questo metodo tutti gli utenti che vengono autorizzati da AUTH.logged risultano essere utenti pippo ;)
kentaromiura wrote:
eh, son appena passato a 2.0 ..

allora, benvenuto nel mondo del non ritorno!
scherzi a parte, davvero, cerca di leggere quei due papiri di ricky, vedrai che l'argomento è interessante.

io l'autenticazione la faccio per mezzo di un DB centralizzato esistente appunto quel AUTH.logged serve a interpellare il db,
volevo solo sfruttare la possibilità di mostrare una parte del sito solo ad una certa schiera di utenti(appunto quelli con lo stesso ruolo) mettendo all'interno di una subdirectory il seguente web.config

perchè non un custom provider per le membership? soluzione molto più elegante, ottimale e che manda a casa le session.

in tal modo naturalmente gli utenti non loggati vedono comunque una parte di sito, e modificando leggermente la login (o mettendone un altra in un area diversa)
posso gestire la parte di amministrazione ecc..

ribadisco che mi vengono i brividi...
Membership API risponde a molti bisogni che hai, a patto che però non usi Pippo come l'utente anonimo, anche perchè ASP.NET 2.0 ha già funzioni del genere integrate, per cui è davvero un peccato. vedi:
http://tags.aspitalia.com/Membership_API+Roles_API/

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
31 messaggi dal 04 novembre 2004

Daniele Bochicchio ha scritto:
allora, benvenuto nel mondo del non ritorno!
scherzi a parte, davvero, cerca di leggere quei due papiri di ricky, vedrai che l'argomento è interessante.

credo di averli letti in caso linkami..


perchè non un custom provider per le membership? soluzione molto più elegante, ottimale e che manda a casa le session.

per 2 motivi:
1) ho poco tempo a disposizione(poi in futuro magari vedo se posso sistemare..)
2) quei 2 dati in realtà non sono user e password ma 2 numeri di serie
che mi occorrono in seguito nel sito...
3) te l'ho detto che sono appena passato a 2.0 ?
4) ma non erano 2 i punti ?!?


ribadisco che mi vengono i brividi...
Membership API risponde a molti bisogni che hai, a patto che però non usi Pippo come l'utente anonimo, anche perchè ASP.NET 2.0 ha già funzioni del genere integrate, per cui è davvero un peccato. vedi:
http://tags.aspitalia.com/Membership_API+Roles_API/


vabbe' ma Pippo era solo un esempio.. mica e' veramente il mio user e password generiche..

e proprio per sfruttare il modello di autorizzazione esistente che ho strutturato cosi'..

purtroppo potendo creare la tabella users da 0 avrei usato la gestione degli utenti integrata...
31 messaggi dal 04 novembre 2004
bene, ho riscritto un po di codice, in particolare ho scritto un membershipprovider  , visto che a me interessava solo l'autenticazione e non la gestione degli utenti la maggiorparte del codice e' :
throw new NotSupportedException();


ora volevo eliminare pure le sessioni, cosi' mi sono detto:
implementiamo una classe che estende IIdentity e aggiungiamo i campi che mi servono..


perfetto, e in debug funziona,
public override bool ValidateUser(string username, string password)
    {
        bool log = AUTH.logged(username, int.Parse(password));
        if (log)
        {

//DOVE pippo e' il mio utente generico

            FormsAuthentication.SetAuthCookie("pippo", false);
            
            CustomIdentity gi = new CustomIdentity("pippo", username, password);
            RolePrincipal RP = new RolePrincipal(gi);

            HttpContext.Current.User = RP;
        }
        return log;
        
       
    }

}

in debug vedo che HttpContext.Current.User e' di tipo CustomIdentity,
effettuo il redirect e ..PUFF!
mi diventa di tipo

System.Web.Security.Forms.Identity
per cui
Response.Write(((CustomIdentity)(HttpContext.Current.User.Identity)).userName);

mi torna errore in Casting



ho dato un occhiata alle varie ML ma sembra non sia possibile fare cosi', l'unico modo e' salvare nella session e ricaricarla ad ogni richiesta.
non mi toccherà mica tenere le sessioni?




P.s. come già detto sto sperimentando molto con il codice e il ValidateUser e' provvisorio..

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.