Neste post, vamos escrever um Storage Provider para ASP.NET Core Identity, do zero, utilizando RavenDB como mecanismo de persistência.

O código fonte está disponível no meu Github.

O que é ASP.NET Core Identity?

ASP.NET Core Identity é um sistema de controle de usuários para aplicativos web desenvolvidos com ASP.NET core, incluindo membership, login, e dados de usuário. ASP.NET Core Identity permite que adicionemos funcionalidades de login em nossas aplicações e torna fácil a customização dos dados sobre o usuário logado.

O que é um storage provider?

O Storage Provider é um componente de nível mais baixo na arquitetura do ASP.NET Core Identity que fornece classes que determinam como dados de usuários e roles são armazenados.

Por padrão, ASP.NET Core Identity armaznea informações em um banco de dados SQL Servier usando Entity Framework. Entretanto, talvez queiramos usar uma estratégia de persistência diferente, como usar um banco de dados RavenDB, por exemplo. Neste caso, precisamos usar/escrever um provider personalizado e integrar esse provider em nosssa aplicação.

Um storage provider deve forneceer implementações para duas interfaces: IUserStore e IRoleStore.

Começando o desenvolvimento de Storage Provider para ASP.NET Core Identity

Eu recomendo fortemente a criação de um projeto .NET standard separado para a implementação. Embora isso não seja mandatório, essa prática facilita a manutenção do código e o reuso.

Para implementar seu storage provider, precisamos instalar o pacote Nuger Microsoft.AspNetCore.Identity no projeto. Neste post, estamos usando RavenDB como mecanismo de persistência. Logo, também é necessário instalar o pacote RavenDB.Client NuGet package.

Implementando a gestão de dados básicos dos usuários

O elemento mais importante de um storage provider é o User Store. O User Store é uma classe que provê métodos para todas as operações com dados para manter o usuário.

Uma abordagem mínima precisa implementar a interface IUserStore .

using System;
using System.Threading;
using System.Threading.Tasks;

namespace Microsoft.AspNetCore.Identity
{
    public interface IUserStore<TUser> : IDisposable where TUser : class
    {
        Task<string> GetUserIdAsync(TUser user, CancellationToken cancellationToken);
        Task<string> GetUserNameAsync(TUser user, CancellationToken cancellationToken);
        Task SetUserNameAsync(TUser user, string userName, CancellationToken cancellationToken);
        Task<string> GetNormalizedUserNameAsync(TUser user, CancellationToken cancellationToken);
        Task SetNormalizedUserNameAsync(TUser user, string normalizedName, CancellationToken cancellationToken);
        Task<IdentityResult> CreateAsync(TUser user, CancellationToken cancellationToken);
        Task<IdentityResult> UpdateAsync(TUser user, CancellationToken cancellationToken);
        Task<IdentityResult> DeleteAsync(TUser user, CancellationToken cancellationToken);
        Task<TUser> FindByIdAsync(string userId, CancellationToken cancellationToken);
        Task<TUser> FindByNameAsync(string normalizedUserName, CancellationToken cancellationToken);
    }
}

Há métodos para criar, atualizar, apagar e recuperar dados de usuários. Há também métodos para obter e setar valores do objeto que mantem os dados do usuário.

O objeto User

Não há constraints para definir a interface pública do objeto User e isso é realmente interessante. O desenvolvedor é livre para definir o objeto da forma como desejar. A implementação básica, que vimos acima, requer apenas três propriedades. Então, nesse exemplo, vamos começar simples.


public class RavenDBIdentityUser
{
    public RavenDBIdentityUser(string userName) : this()
    {
        UserName = userName ?? throw new ArgumentNullException(nameof(userName));
    }

    public string Id { get; internal set; }
    public string UserName { get; internal set; }
    public string NormalizedUserName { get; internal set; }
}

Preparando-se para salvar e recuperar dados

Agora, é hora de começarmos a implementar nossa UserStore

public partial class RavenDBUserStore<TUser, TDocumentStore> :
    IUserStore<TUser>,
    where TUser : RavenDBIdentityUser
    where TDocumentStore: class, IDocumentStore
{
    public IdentityErrorDescriber ErrorDescriber { get; }
    public TDocumentStore Context { get; }

    private readonly Lazy<IAsyncDocumentSession> _session;

    public RavenDBUserStore(
        TDocumentStore context,
        IdentityErrorDescriber errorDescriber = null
    )
    {
        ErrorDescriber = errorDescriber;
        Context = context ?? throw new ArgumentNullException(nameof(context));

        _session = new Lazy<IAsyncDocumentSession>(() =>
        {
            var session = Context.OpenAsyncSession();
            session.Advanced.UseOptimisticConcurrency = true;
            return session;
        }, true);
    }

    public IAsyncDocumentSession Session 
        => _session.Value;

    public Task SaveChanges(
        CancellationToken cancellationToken = default(CancellationToken)
        ) => Session.SaveChangesAsync(cancellationToken);

    // ...

    #region IDisposable
    private void ThrowIfDisposed()
    {
        if (_disposed)
        {
            throw new ObjectDisposedException(GetType().Name);
        }
    }

    private bool _disposed;
    public void Dispose()
    {
        Session.Dispose;
        _disposed = true;
    }
    #endregion
}

Neste código, iniciamos a implementação da interface IUserStore.

Eu continuo usando um tipo genérico para especificar o tipo que será utilizado para armazenar dados do usuário. A única restrição força que o tipo seja uma especialização da classe RavenDBIdentityUser que definimos antes. Esta decisão de design torna fácil ampliar o modelo para salvar mais dados.

O construtor espera por uma instância de IDocumentStore. Nós vamos usar este objeto para conectar ao banco de dados RavenDB (Se deseja aprender mais sobre RavenDB, considere inscrever-se RavenDB bootcamp disponível gratuitamente on-line).

Nós vamos utilizar a biblioteca assíncrona do RavenDB que é bem fácil.

Criando, carregando, atualizando e excluindo usuários

Com uma sessão, é bem fácil escrever código para criação, carga e atualização de dados de usuários.

public async Task<IdentityResult> CreateAsync(
    TUser user,
    CancellationToken cancellationToken = default(CancellationToken)
    )
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    cancellationToken.ThrowIfCancellationRequested();

    await Session.StoreAsync(user, cancellationToken);
    await SaveChanges(cancellationToken);

    return IdentityResult.Success;
}

public Task<TUser> FindByIdAsync(string userId, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    cancellationToken.ThrowIfCancellationRequested();
    return Session.LoadAsync<TUser>(userId, cancellationToken);
}

public async Task<IdentityResult> UpdateAsync(TUser user, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    var stored = await Session.LoadAsync<TUser>(user.Id, cancellationToken);
    var etag = Session.Advanced.GetEtagFor(stored);

    await Session.StoreAsync(user, etag, cancellationToken);

    try
    {
        await SaveChanges(cancellationToken);
    }
    catch (ConcurrencyException)
    {
        return IdentityResult.Failed(ErrorDescriber.ConcurrencyFailure());
    }

    return IdentityResult.Success;
}

public async Task<IdentityResult> DeleteAsync(
    TUser user,
    CancellationToken cancellationToken = default(CancellationToken)
    )
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    Session.Delete(user.Id);

    try
    {
        await SaveChanges(cancellationToken);
    }
    catch (ConcurrencyException)
    {
        return IdentityResult.Failed(ErrorDescriber.ConcurrencyFailure());
    }

    return IdentityResult.Success;
}

Não precisamos pensar em esquema de tabelas – RavenDB é um banco de dados schemaless. RavenDB vai salvar o objeto sem reclamações, mesmo que a interface pública da classe mude completamente. Não há necessidade de pensar a respeito de modificações neste código no futuro. Não há migrations ou nada deste tipo.

Encontrando usuários pelo nome

Agora, vamos escrever o método FindByName
Now, let’s write the FindByName method.

public Task<TUser> FindByNameAsync(string normalizedUserName, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    return Session.Query<TUser>().FirstOrDefaultAsync(
        u => u.NormalizedUserName == normalizedUserName, cancellationToken
    );
}

Quanto performático é esse código? Usando Raven, é extremamente rápido! RavenDB irá criar um índice automaticamente para executar essa query da forma mais rápida possível.

Obtendo e setando propriedades do objeto User

Como você sabe, nós estamos livres para definir a interface pública do objeto User. Logo, a interface IUserStore, define alguns métodos auxiliares onde podemos definir a lógica que deve ser empregada para setar e obter dados.

public Task<string> GetUserIdAsync(TUser user, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();
    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    return Task.FromResult(user.Id);
}

public Task<string> GetUserNameAsync(TUser user, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    return Task.FromResult(user.UserName);
}

public Task SetUserNameAsync(TUser user, string userName, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    if (userName == null)
    {
        throw new ArgumentNullException(nameof(userName));
    }

    user.UserName = userName;

    return Task.CompletedTask;
}

public Task<string> GetNormalizedUserNameAsync(TUser user, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    return Task.FromResult(user.NormalizedUserName);
}

public Task SetNormalizedUserNameAsync(TUser user, string normalizedName, CancellationToken cancellationToken = default(CancellationToken))
{
    cancellationToken.ThrowIfCancellationRequested();
    ThrowIfDisposed();

    if (user == null)
    {
        throw new ArgumentNullException(nameof(user));
    }

    if (normalizedName == null)
    {
        throw new ArgumentNullException(nameof(normalizedName));
    }

    user.NormalizedUserName = normalizedName;

    return Task.CompletedTask;
}

Simples assim.

Fazendo gestão avançada dos dados dos usuários

Como você pode ver, a implementação básica do User Store não suporta alguns conceitos importantes, como senhas, emails, claims, bloqueio de usuários, roles, etc.

Todas essas funcionalidades podem ser adicionadas, conforme for necessário através da implementação de algumas interfaces opcionais. Estas interfaces apenas definem outros métodos auxiliares que recuperam e setam valores no objeto user.

Você encontra uma implementação dessas importantes interfaces opcionais no meu GitHub.

Gestão de Roles

Um bom storage provider deve implementar também um Role Store. Trata-se de uma classe que provê métodos para todas as operações com dados envolvendo Roles.

public interface IRoleStore<TRole> : IDisposable where TRole : class
{
    Task<IdentityResult> CreateAsync(TRole role, CancellationToken cancellationToken);
    Task<IdentityResult> DeleteAsync(TRole role, CancellationToken cancellationToken);
    Task<TRole> FindByIdAsync(string roleId, CancellationToken cancellationToken);
    Task<TRole> FindByNameAsync(string normalizedRoleName, CancellationToken cancellationToken);
    Task<string> GetNormalizedRoleNameAsync(TRole role, CancellationToken cancellationToken);
    Task<string> GetRoleIdAsync(TRole role, CancellationToken cancellationToken);
    Task<string> GetRoleNameAsync(TRole role, CancellationToken cancellationToken);
    Task SetNormalizedRoleNameAsync(TRole role, string normalizedName, CancellationToken cancellationToken);
    Task SetRoleNameAsync(TRole role, string roleName, CancellationToken cancellationToken);
    Task<IdentityResult> UpdateAsync(TRole role, CancellationToken cancellationToken);
}

Como pode ver, a ideia aqui é basicamente a mesma adotada no design de IUserStore. Logo, podemos seguir a mesma estratégia de implementação.

Novamente, você encontra um exemplo de implementação da interface IRoleStore no meu GitHub.

Métodos auxiliares para tornar a configuração do IdentityBuilder mais fácil

Agora que temos nossas implementações para IUserStore e IRoleStore, precisamos escrever um método auxiliar para configurar o IdentityBuilder para usar essas implementações.

public static class IdentityBuilderExtensions
{
    public static IdentityBuilder UseRavenDBDataStoreAdaptor<TDocumentStore>(
        this IdentityBuilder builder
    ) where TDocumentStore : class, IDocumentStore
        => builder
            .AddRavenDBUserStore<TDocumentStore>()
            .AddRavenDBRoleStore<TDocumentStore>();
        
    private static IdentityBuilder AddRavenDBUserStore<TDocumentStore>(
        this IdentityBuilder builder
    )
    {
        var userStoreType = typeof(RavenDBUserStore<,>).MakeGenericType(builder.UserType, typeof(TDocumentStore));

        builder.Services.AddScoped(
            typeof(IUserStore<>).MakeGenericType(builder.UserType),
            userStoreType
        );

        return builder;
    }

    private static IdentityBuilder AddRavenDBRoleStore<TDocumentStore>(
        this IdentityBuilder builder
    )
    {
        var roleStoreType = typeof(RavenDBRoleStore<,>).MakeGenericType(builder.RoleType, typeof(TDocumentStore));

        builder.Services.AddScoped(
            typeof(IRoleStore<>).MakeGenericType(builder.RoleType),
            roleStoreType
        );

        return builder;
    }
}

Feito!

Usando!

Estamos prontos para parar de usar Entity Framework e SQL Server (ugh) e começar a usar RavenDB para armazenar usuários e Roles em nossas aplicações com ASP.NET core.

Assumindo que você já esteja utilizando RavenDB, a configuração será algo similar ao que segue:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    //services.AddDbContext<ApplicationDbContext>(options =>
    //        options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]));

    services.AddSingleton(DocumentStoreHolder.Store)

    services.AddIdentity<ApplicationUser, RavenDBIdentityRole>()
        .UseRavenDBDataStoreAdaptor<IDocumentStore>()
        .AddDefaultTokenProviders();

    services.AddMvc();

    // Add application services.
    services.AddTransient<IEmailSender, AuthMessageSender>();
    services.AddTransient<ISmsSender, AuthMessageSender>();
}

Observe que precismos mudar a classe base adotada de AplicationUser para RavenDBIdentityUser.

Há um demo executável no meu GitHub.

Era isso.

1 comentário

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *