427 messaggi dal 13 novembre 2009
Salve,
su configure
app.UseAuthentication();
su configureservice
services.ConfigureApplicationCookie(options =>
{
options.LoginPath = "/Account/Login";
options.SlidingExpiration = true;
options.Cookie.Name = "CookieAuth";
options.Cookie.IsEssential = true;
options.Cookie.Expiration = TimeSpan.FromMinutes(60);

});
La login la fa correttamente
_signInManager.PasswordSignInAsync

ma mi spiegate nel controller Home se verifico User.Indetity perché tutto le sue proprie sono null.
L'oggetto è istanziato ma ad esempio non autentitcato e claims a zero

F.
427 messaggi dal 13 novembre 2009
app.UseAuthentication() va dichiarato primo si app.UseMvc()....
ci sono arrivato per caso ma trovo assurdo che non ci sia nulla che ti dia una mano a capire!
F.
11.886 messaggi dal 09 febbraio 2002
Contributi
L'ordine con cui usi i middleware è importante. La richiesta viene gestita dai middleware in quell'esatto ordine per cui l'autenticazione deve verificarsi prima, in modo che l'identità dell'utente sia stata già ricreata nel momento in cui le action dei tuoi controller vanno in esecuzione.


ci sono arrivato per caso ma trovo assurdo che non ci sia nulla che ti dia una mano a capire!


Leggi questo
https://www.aspitalia.com/script/1229/Configurare-Middleware-Servizi-ASP.NET-Core.aspx

ciao,
Moreno
Modificato da BrightSoul il 01 agosto 2019 14:21 -

Enjoy learning and just keep making
427 messaggi dal 13 novembre 2009
Altra domanda!
I metodi per la validazione dell'utenza in fase di login utilizzando Identity, ad es. signInManagerPasswordSignInAsync vanno a leggere il database tramite lo UserStore da me creato? Mi domandavo se fosse possibile modificare nomi tabella e nomi campi delle tablelle ApplicationUser, ApplicationRole ecc...
Non utilizzo EntityFramework e quindi CodeFirst, ma Dapper
Banalmente basterebbe cambiare il nome alle classi?
UserStore : IUserStore<ApplicationUser>, IUserPasswordStore<ApplicationUser>, IUserRoleStore<ApplicationUser>
diventerebbe
UserStore : IUserStore<Utenti>, IUserPasswordStore<Utenti>, IUserRoleStore<Utenti>
e
RoleStore : IRoleStore<ApplicationRole>
in
RoleStore : IRoleStore<Ruoli>

Ma se volessi utilizzare il pluralize, ovvero la tabella si chiama Utenti e la classe Utente

grazie
F.
Modificato da flaviovb il 01 agosto 2019 15:27 -
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,

signInManagerPasswordSignInAsync vanno a leggere il database tramite lo UserStore da me creato?


Sì ma non ho capito bene. Hai creato un tuo UserStore personalizzato e ti sei messo a implementare tutte le interfacce tipo IUserStore, IUserPasswordStore e così via?

Se , beh, sei tu a dover decidere quali saranno i comandi INSERT, UPDATE e DELETE da fare nel database, e perciò dovrai anche scegliere i nomi delle tabelle.

Se no, e perciò stai usando Entity Framework Core, per cambiare i nomi delle tabelle devi andare nella classe ApplicationDbContext che hai nel progetto e aggiungere questo metodo (o integrarlo se già esiste).

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);  
            modelBuilder.Entity<IdentityUser>().ToTable("NomeTabellaUtenti");
            modelBuilder.Entity<IdentityRole>().ToTable("NomeTabellaRuoli");
            //...
        }


Poi aggiungi una migration e aggiorni il database. Perciò da riga di comando fai:
dotnet ef migrations add "CambioNomiTabelle"
dotnet ef database update


Però non sono sicuro che il codice che hai postato sia quello corretto perché ci sono molte cose che dovresti specificare, tipo qual è la classe che stai usando per rappresentare l'utente, quale rappresenta il ruolo, e così via.

ciao,
Moreno

Enjoy learning and just keep making
427 messaggi dal 13 novembre 2009
No ho solo implementato le classi
RoleStore : IRoleStore<ApplicationRole>
UserStore : IUserStore<ApplicationUser>, IUserPasswordStore<ApplicationUser>, IUserRoleStore<ApplicationUser>
ovviamente implementando i metodi che le replative interfacce prevedono.
ApplicationDbContext non la ho implementata, le tabelle le ho create a mano sul database.
Qunindi immagino che se mappo
UserStore : IUserStore<Utente> funziona, ma se volessi cambiare i nomi alle proprietà. Ad esempio se volessi far diventare ApplicationRole => Ruoli e ApplicationRole.Name => Ruoli.Nome
Cambiare i nomi alle proprietà è banale e cambiare lo script sql per la insert o l'update idem, ma
signinManager.PasswordSignInAsync(Utente.Nome, Utente.Password)?
Insernamente il metodo utilizzo il mio UserStore per verificare la password, ovvero fa la retrieve dell'oggetto Utente e poi verifica con il campo PAsswordHash Utente.Password?
F
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


ovviamente implementando i metodi che le replative interfacce prevedono.

Ok, chiaro.


ApplicationDbContext non la ho implementata

Giusto, infatti ApplicationDbContext non ti serve dato che hai scritto tu la logica di persistenza di utenti e ruoli quando hai implementato le suddette interfacce.


Qunindi immagino che se mappo
UserStore : IUserStore<Utente> funziona

Assolutamente sì, tu sei libero di creare quella classe Utente come preferisci. Puoi metterci dentro delle proprietà scritte in italiano come NomeUtente, Nome, Cognome, e così via. ASP.NET Core Identity non ti obbliga ad avere proprietà scritte in inglese.

Questo vale anche per la classe del ruolo. Puoi fare:
RoleStore : IRoleStore<Ruolo>

E nella classe Ruolo metti le proprietà che vuoi, tipo "Nome".


signinManager.PasswordSignInAsync(Utente.Nome, Utente.Password)?
Insernamente il metodo utilizzo il mio UserStore per verificare la password

Esatto, verrà invocato il metodo GetPasswordHashAsync del tuo UserStore.
ASP.NET Core è open source, lo puoi vedere qui.

Ci si arriva seguendo le molliche di pane, dopo essere partiti dal SignInManager che è definito qui.

ciao,
Moreno

Enjoy learning and just keep making
427 messaggi dal 13 novembre 2009
Si essendo open lo stavo verificando intanto su git.
Ultima cosa! per comodità utilizzo identity perché ha già le logiche si gestione del cookie come anche la scadenza e lo slidingexpiration, tutto configurabile tipo aspnetmembership.
Vorrei implementare maschere con angularjs in attesa di blazor ufficiale. In entrambe i casi immagino che facendo delle call a controllerapi se pongo Authorize scatta in automatico il controllo del cookie rilasciato?
Aggiungerei poi un mio customfilter che verifica altro intercettando l'utente (User.identity) e collegandomi al db per controllare altri dati prima della action
F.
Modificato da flaviovb il 01 agosto 2019 21:52 -

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.