Arquivo da categoria: ASP.NET Identity

Integrando ASP.NET Core com ASP.NET MVC 5

Publicado em por

Migrando para o ASP.NET Core? Não é necessário migrar todo o projeto de uma única vez, utilize migrações modulares e compartilhe o Cookie de autorização de usuários.

O ASP.NET Core está pronto e muitas demandas de migração de projetos ASP.NET 4.X para a nova plataforma irão surgir. Como planejar e executar esta migração?

ASP.NET Core & ASP.NET 4.X

Uma migração total pode ser complexa, afinal vai exigir a alocação de diversas pessoas e enquanto isto as duas aplicações precisarão receber futuras implementações. Alguns projetos são tão grandes que simplesmente não seriam migrados se esta fosse a única alternativa, seria impossível atender as duas demandas simultaneamente.

Por que não ter duas aplicações?

Não há motivos para uma migração total se sua aplicação já funciona bem. Portar parcialmente módulos da aplicação para um projeto ASP.NET Core é uma alternativa bem mais interessante e que vai exigir muito menos esforço.

Imagine que em sua aplicação o módulo de gestão de Produtos funciona no ASP.NET MVC 5 e o módulo de gestão de Clientes no ASP.NET Core, o usuário final mal poderá perceber a diferença!

Integração de dados entre duas aplicações.

Certo! Posso migrar parcialmente, mas como faço a integração entre os dados que estão em aplicações diferentes?

Uma aplicação que utiliza uma boa arquitetura e uma boa modelagem estratégica pode facilmente integrar diversas entidades através dos ORM’s. Se a aplicação possuir uma modelagem DDD cada Bounded Context resolve seus próprios problemas, migre um BC de cada vez! (está mais fácil do que você imagina).

Compartilhando o usuário entre duas aplicações

Este é o grande foco da abordagem que apresento, como realizar uma integração para uma aplicação ASP.NET Core compartilhar o mesmo usuário de uma aplicação ASP.NET MVC 5.

Disponibilizei um novo repositório no meu GitHub com o projeto AspNetInterop este projeto implementa exatamente este cenário onde duas aplicações ASP.NET Core 1.1 e ASP.NET MVC 5 compartilham o mesmo Usuário, Cookies, Claims e Token para o AntiForgery.

Para reproduzir este projeto você precisa utilizar alguns Nuget Packages

Utilize o mesmo Cookie entre as aplicações

Esta abordagem faz a utilização do ASP.NET Identity, mas é possível produzir o mesmo resultado utilizando somente as classes do Microsoft.Owin.Security.

O importante é setar o mesmo cookie entre as duas aplicações:

services.AddIdentity<ApplicationUser, IdentityRole>(options =>
{
    options.Cookies = new Microsoft.AspNetCore.Identity.IdentityCookieOptions
    {
        ApplicationCookie = new CookieAuthenticationOptions
        {
            AuthenticationScheme = "Cookie",
            LoginPath = new PathString("/Account/Login/"),
            AccessDeniedPath = new PathString("/Account/Forbidden/"),
            AutomaticAuthenticate = true,
            AutomaticChallenge = true,
            CookieName = ".AspNet.SharedCookie"

            // If you have subdomains use this config:
            CookieDomain = "localhost"
        };
    })
    .AddEntityFrameworkStores<ApplicationDbContext>()
    .AddDefaultTokenProviders();

É necessário que as aplicações rodem no mesmo nome de domínio, se você tiver sub-dominios para cada aplicação basta setar a raíz do domínio em CookieDomain.

Selecione um repositório para Data Protection

O exemplo está utilizando um diretório como repositório, mas o ASP.NET Core 1.1 já suporta Redis, Azure Blob Storage e Azure Key Vault.

No ASP.NET MVC 5 além de configurar o Identity para utilizar o mesmo cookie (verifique implementação no código fonte) é necessário configurar o AntiForgery para que o usuário consiga utilizar a mesma chave entre as aplicações, para isto é necessário esta configuração no Global.asax

AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;

O AntiForgery faz a validação baseada em claims e no cookie do usuário logado.

Migre o módulo de gestão de usuários primeiro

Para utilizar este recurso é importante que esteja utilizando o ASP.NET Core com o ASP.NET Identity 3.0, portanto eu sugiro que este seja o primeiro módulo a ser migrado. A implementação deste projeto compartilha a mesma base do ASP.NET Identity entre as aplicações.

Compartilhando Cookies entre ASP.NET Core e ASP.NET MVC 5

Esta implementação foi baseada no repositório idunno.CookieSharing do qual o Scott Hanselman faz parte dos integrantes. O projeto que disponibilizo no repositório AspNetInterop é uma melhoria da implementação original, no meu projeto as melhorias implementadas foram:

  • Utilização do ASP.NET Identity ao invés do Cookie Middleware
  • Implementação de controle de acesso com base em claims para o ASP.NET Core e ASP.NET MVC 5 (cada um possui uma implementação diferente devido a forma de autorizar usuários no ASP.NET Core ter mudado)
  • Compartilhamento do Cookie no AntiForgery
  • CRUD’s de entidades em cada aplicação
  • Navegação integrada para o usuário não notar a mudança

Este projeto não conta com divisão em camadas para implementar separação de responsabilidades de Dados, Negócios e etc, porém é muito simples de implementar, pois isto não gera impacto na implementação existente.

Código fonte

Caso esteja interessado em conhecer mais sobre ASP.NET, DDD, Padrões de Arquitetura como CQRS, Event Sourcing e boas práticas de desenvolvimento não deixe de conferir as ementas dos meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Desacoplando o ASP.NET Identity do MVC e Domínio

Publicado em por

O ASP.NET Identity é uma ótima solução para a gestão dos usuários em sua aplicação, porém seu design é diretamente acoplado ao ASP.NET MVC e também devemos evitar de utilizar suas referências no domínio da aplicação.

Desacoplando o ASP.NET Identity. Finalmente após muitos pedidos eu consegui colocar a mão na massa e desenvolver um projeto modelo para ser usado como referência.

Desacoplando o ASP.NET Identity do MVC e Domínio

Como sabemos o ASP.NET Identity depende diretamente do EF (ou outros), Owin e System.Web, logo todas as implementações do ASP.NET Identity ficam de alguma forma acopladas em nossa camada de apresentação. Quando possuímos uma aplicação onde o usuário é uma peça importante no negócio existe a necessidade de representá-lo na camada de domínio, porém é altamente recomendado que a camada de domínio não conheça tecnologias terceiras (Identity, EF, outros).

Como resolver esse problema?

Foi após alguns estudos que cheguei no modelo que considero ser a “melhor abstração possível”, pois para o ASP.NET Identity funcionar na camada de apresentação é obrigatório levar algumas dependências, porém desde que esteja isolado em outra camada já conseguiremos ótimas boas vantagens.

Aviso: Caso você não conheça o ASP.NET Identity, DDD e Injeção de dependência sugiro que comece pelos tutoriais:

Neste tutorial você encontrará as seguintes tecnologias utilizadas

  • ASP.NET MVC 5
  • ASP.NET Identity 2
  • Entity Framework 6
  • Fluent API
  • Injeção de Dependência com Simple Injector
  • Owin
  • RestSharp para implementação do Twilio API (SMS)

Existem dois grandes objetivos nesta proposta, o primeiro objetivo é a reutilização, pois com um uma única solução (camada) de gestão de usuários é possível atender N aplicações, facilitando o gerenciamento e manutenção.

O segundo objetivo é permitir que a camada de domínio represente o usuário de forma abstraída, logo não existe referência direta do IdentityUser no domínio, porém é possível consultar os dados de usuário e incluir / modificar as informações salvas.

O primeiro passo é abstrair tudo, mover as dependências do Identity para uma camada isolada, depois injetar no MVC os objetos necessários, para essa implementação eu utilizei o Simple Injector, que como o próprio nome diz, é bem simples, rápido e atendeu bem a necessidade.

Com o Identity isolado e injetado devidamente na camada de apresentação (MVC) basta criar uma camada de acesso a dados que irá fornecer meios do domínio consumir dados do usuário de forma abstraída. A grande sacada está no uso correto do Fluent API e claro muita injeção de dependência.

A solução desde modelo não visa atender completamente a filosofia do DDD, pois procurei simplificar o bastante para deixar simples de modificar, por exemplo adicionando uma camada de Application. Portanto quem utilizar esta arquitetura deve estar ciente que algumas coisas a mais ainda precisam ser feitas.

Gostaria de ressaltar também que o template de projeto ASP.NET MVC que o Visual Studio fornece possui vários problemas de design de código. As controllers de Account e Manage do usuário precisaram ser parcialmente re-escritas para atender a injeção do Identity, problemas como mais de um construtor público e utilização do pattern (ou anti pattern?) Service Locator foram encontrados e retirados.

Para quem quiser acompanhar em detalhes técnicos toda a implementação dessa solução eu preparei o vídeo a seguir.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub, caso queira propor alguma melhoria faça um Pull Request, será muito bem recebido.

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Customizando Nomes de Tabelas e Campos no ASP.NET Identity

Publicado em por

O ASP.NET Identity possui um padrão de nomenclatura para suas tabelas e campos, muitas vezes é necessário customizar este padrão para atender as necessidades da aplicação, confira como é simples realizar esta tarefa.

Como apresentado aqui algumas vezes, o ASP.NET Identity é um componente muito completo e simples de customizar, ele é escrito baseado no conceito Code-First e sua arquitetura é bem aberta possibilitando a customização de funcionalidades, comportamentos e até mesmo fonte de dados.

As tabelas que o ASP.NET Identity cria automaticamente segue o mesmo processo de qualquer desenvolvimento Code-First, permitindo que o desenvolvedor mapeie na configuração do DbContext toda a modelagem da base que será criada.

Vamos abordar de forma muito simples e pontual como realizar este processo partindo do pré-suposto que sua aplicação foi criada com base no template de aplicação ASP.NET MVC já com o ASP.NET Identity configurado. Independente deste fato, o que é realmente necessário fazer é editar o contexto do ASP.NET Identity.

Uma dica válida para qualquer situação é manter sempre o contexto do ASP.NET Identity separado do contexto da aplicação.

Iremos trabalhar também com a hipótese de customização do IdentityUser através de sua classe derivada ApplicationUser. Vamos ao código.

public class ApplicationUser : IdentityUser
{
    public string Apelido { get; set; }
}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection")
    {
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<IdentityUser>()
            .ToTable("Usuarios")
            .Property(p => p.Id)
            .HasColumnName("UsuarioId");

        modelBuilder.Entity<ApplicationUser>()
            .ToTable("Usuarios")
            .Property(p => p.Id)
            .HasColumnName("UsuarioId");

        modelBuilder.Entity<IdentityUserRole>()
            .ToTable("UsuarioPapel");

        modelBuilder.Entity<IdentityUserLogin>()
            .ToTable("Logins");

        modelBuilder.Entity<IdentityUserClaim>()
            .ToTable("Claims");

        modelBuilder.Entity<IdentityRole>()
            .ToTable("Papeis");
    }
}

Na classe ApplicationUser realizamos uma pequena customização adicionando um novo campo (Apelido), apenas para enfatizar a situação.

Na classe ApplicationDbContext repare que ela herda de IdentityDbContext, que é a real classe de contexto do ASP.NET Identity onde ela internamente herda de DbContext.

A ideia de existir a classe ApplicationDbContext é justamente fornecer um contexto para customização, uma vez que a classe IdentityDbContext faz parte dos assemblies do ASP.NET Identity e não é possível ser alterada.

Baseado no conceito da herança o que basicamente fizemos foi sobrescrever o método OnModelCreating da classe base para alterarmos os padrões de nomenclatura. Utilizamos Fluent API para realizar esse mapeamento trocando os nomes das tabelas e campos.

Essa troca não impacta no funcionamento interno do ASP.NET Identity, pois as classes internas permanecem intactas, apenas o mapeamento do modelo objeto / relacional foi modificado e a aplicação irá seguir o que a modelagem manda.


modelBuilder.Entity<IdentityUser>()
    .ToTable("Usuarios")
    .Property(p => p.Id)
    .HasColumnName("UsuarioId");

modelBuilder.Entity<ApplicationUser>()
    .ToTable("Usuarios")
    .Property(p => p.Id)
    .HasColumnName("UsuarioId");

Repare que as duas classes (IdentityUser, ApplicationUser) foram mapeadas para mesma tabela, pois só assim seria possível mapear a classe de usuários e ao mesmo tempo aplicar as customizações, no final tudo vira uma única tabela com informações de ambas as classes.

ASP.NET Identity Tabelas e Campos Customizados

Detalhes adicionais

  • É possível utilizar todos os recursos do Fluent API nessa abordagem, sendo possível modificar tipo dos campos, inserir índices, criar novos relacionamentos, mapear novas tabelas e etc.
  • É possível realizar todo este mapeamento em uma outra classe e configurar esta classe no contexto (assim como fazemos com as nossas entidades no Fluent API).

Simples?
Agora é possível incorporar o ASP.NET Identity ao seu modelo já existente de base de usuários, a única premissa é que todas as tabelas e campos do ASP.NET Identity sejam representados (mapeados) de alguma forma no banco de dados existente.

Vamos continuar a enriquecer este artigo participando nos comentários abaixo com dúvidas, complementos e feedbacks.

Referências

Este artigo foi escrito durante minha participação na Campus Party 2015 #CPBR8

ASP.NET Identity – Tutorial Completo – Demos, Vídeo, Slides

Publicado em por

O ASP.NET Identity é o novo componente de Membership do ASP.NET que já está na versão 2.1, aprenda neste tutorial as suas funcionalidades, tecnologia base e como implementá-lo e aproveitar todos os recursos.

ASP.NET Identity

O ASP.NET Identity foi lançado junto com o ASP.NET MVC 5 e o Visual Studio 2013 e logo foi muito bem aceito pela comunidade técnica, pois possui uma arquitetura bem aberta, limpa e modularizada de forma que proporciona grande facilidade de customização e testabilidade.

Historicamente o ASP.NET forneceu 4 componentes de Membership

  • (2002 – 2005) – Não possuía nenhum componente
  • (2005 – 2010) – Membership Provider
  • (2010 – 2012) – Simple Membership
  • (2012 – 2013) – Universal Providers
  • (2013 – Hoje)  – ASP.NET Identity

Características do ASP.NET Identity desde a primeira versão

  • Parte do ONE ASP.NET
  • Customização do perfil do usuário simplificado (escrito em Code First)
  • Controle de persistência de dados (EF ou outros)
  • Totalmente testável (Unity Tests)
  • Role Provider (separação de acessos por perfil)
  • Claims Based
  • Autenticação com redes sociais (FB, Twitter, Google+ e Microsoft Accounts)
  • Integraçao com Active Directory (On-Premisses e Azure)
  • Integração com OWIN (OWIN Middleware based)
  • Entregue via NuGet (Nuget Everywhere)

Alguns aspectos chamaram muito a atenção, como por exemplo ser baseado em Claims (Claims Based), ter sido projetado como um OWIN Middleware e possuir a capacidade de integrar facilmente com as redes sociais através do OAuth 2.0 e OpenID

É possível também integrar com Yahoo e LinkedIn utilizando este pacote adicional desenvolvido pela comunidade técnica. Para customizar a integração com seu próprio mecanismo OAuth, siga este artigo.

Apesar de ter sido muito bem aceito, mesmo assim o ASP.NET Identity recebeu algumas críticas, pois possuía poucos recursos e sua implementação necessitava algumas melhorias, podemos conferir isto no artigo do Brock Allen que escreveu seu próprio componente de Membership baseado nas frustrações que teve com o ASP.NET Membership e o SimpleMembership, além do recém lançado ASP.NET Identity.

Em 2014 o ASP.NET Membership ganhou novas funcionalidades nas suas versões (2.0 e 2.1) Muitas delas listadas como necessárias no artigo acima.

  • Two Factor Authentication
  • Account Lockout
  • Account Confirmation
  • Password Reset
  • Security Stamp (Sign out everywhere)
  • Primary Key extensible for Users and Roles
  • Support IQueryable on Users and Roles
  • Delete User account
  • IdentityFactory Middleware – CreatePerOwinContext (UserManager, DbContext, etc)
  • Enhanced Password Validator
  • SignInManager (Facilidade para aplicar features [Two Factor, Account Lockout, etc])

Recentemente o ASP.NET Identity tornou-se open-source, pois sua primeira versão não tinha ainda o código aberto, você pode ter acesso ao fonte no GitHub do ASP.NET Identity e acompanhar todas as novas implementações além de enviar pull-requests.

O ASP.NET Identity não funciona apenas com ASP.NET MVC, ele trabalha com todo o ecossistema do ASP.NET (MVC, WebAPI, WebPages, WebForms, SignalR).

Conhecer melhor o ASP.NET Identity poderá lhe fornecer muitas vantagens na hora de iniciar um novo projeto, pois não existirá a necessidade de criar um novo componente de identidade e autenticação, você também pode modernizar seu atual componente o tornando compatível com o ASP.NET Identity. Para migração consulte este artigo.

Um outro detalhe é que o ASP.NET Identity pode ser plugado em diversos providers, caso seu projeto não utilize Entity Framework, existe uma série de providers disponíveis.

  • MySQL
  • CodeFluent Entities
  • Azure Table Storage
  • CouchDB
  • Elastic Identity
  • MongoDB
  • Nhibernate
  • RavenDB
  • Redis

Confira mais detalhes sobre implementação dos providers neste artigo.

Para facilitar e apresentar com mais riqueza de detalhes eu gravei um vídeo de 02h40 horas e estou disponibilizando também slides de apresentação além do código fonte do projeto que eu utilizei nas demos.

Slides

Vídeo


* Assine meu canal no Youtube 🙂

Código Fonte

O código fonte está disponível no GitHub, qualquer bug ou sugestão envie uma issue ou pull-request.

Referências

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos design patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Visual Studio 2014 – ASP.NET vNext MVC 6

Publicado em por

A Microsoft disponibilizou para download no dia 03/06/14 o Visual Studio 2014 CTP – Community Technology Preview (build 14.0.21730.1) que tem como principal novidade o suporte para o ASP.NET vNext.

Visual Studio 2014 - ASP.NET vNext - MVC 6

A versão final do Visual Studio 2014 tem lançamento previsto para 2015, mas até então não existe nada definido oficialmente. É uma versão inicial de testes e outras consecutivas devem surgir antes do lançamento da versão final (RTM).

As principais novidades do Visual Studio 2014

  • Suporte à projetos ASP.NET vNext
  • Suporte à nova plataforma de “Managed Code” – Rosyln
  • Novidades e melhorias para C++

Para quem quer experimentar a nova versão do Visual Studio 2014, uma importante recomendação, ele não suporta funcionamento “lado-a-lado” com Visual Studio 2013, seria necessário desinstalar a versão anterior, por ser uma versão de testes não recomenda-se o uso profissional, instale-o em uma máquina virtual e utilize apenas com o propósito de testes.

Para as próximas versões espera-se compatibilidade com as outras instalações do Visual Studio.

Novidades do suporte ao novo ASP.NET vNext

  • ASP.NET vNext Templates
  • ASP.NET vNext Project.json IntelliSense Support
  • Edição de código fonte sem necessidade de parar a aplicação, atualizando apenas com um refresh do browser, funcionalidade obtida através do Roslyn
  • Todos os arquivos incluídos no projeto, no caso de modificação na estrutura de arquivos, estes serão incluidos e atualizados automaticamente.
  • Restore automático de pacotes NuGet através do intellisense do arquivo project.json
  • Métodos de publicação no Microsoft Azure e via File System
  • Suporte à nova versão do ASP.NET Identity 2.0

Caso não conheça o ASP.NET vNext atualize-se neste meu artigo
https://www.eduardopires.net.br/2014/05/o-futuro-do-asp-net-vnext-mvc-6/

Assista ao vídeo (1h05m) com os primeiros passos no ASP.NET vNext utilizando o Visual Studio 2014

  • Novo Visual Studio 2014
  • Criando uma web aplicação padrão ASP.NET vNext MVC 6
  • Rodando uma web aplicação completa (MVC Music Store) ASP.NET vNext MVC 6
  • Novidades do ASP.NET vNext MVC 6 (ViewComponent, Authorize Claims, etc)
  • Hosting (IIS Express, SelfHost, Console Application)

Este vídeo foi dos primeiros passos tanto em ASP.NET vNext como no Visual Studio 2014, muita coisa pode surgir e mudar, todas serão divulgadas conforme anunciadas.

Referências

Vamos continuar a troca de conhecimentos, escreva seu comentário abaixo 😉

Como foi o ASP.NET Brasil Conference 2014

Publicado em por

A comunidade ASP.NET Brasil em comemoração aos seus mais de 1.300 usuários realizou o evento chamado ASP.NET Brasil Conference 2014. Confira como foi.

O agitação do evento começou bem cedo, às 08h00 algumas pessoas já haviam chegado. Rapidamente o auditório que nos foi cedido pela PUC estava lotado, foi necessário colocar cadeiras extras para poder comportar mais pessoas, trabalhamos com a lotação máxima.

O propósito principal do evento foi entregar o máximo de conteúdo sobre ASP.NET de forma que os presentes pudessem aprender sobre recursos disponíveis e abrir os olhos e a mente para diversas possibilidades nesta plataforma.

Foram 6 palestras de conteúdo de alto nível, todas ministradas por MVPs em ASP.NET (7 no total), o que nunca tinha sido realizado antes num evento, foi algo inédito. Tivemos cerca de 122 participantes e o feedback sobre o evento foi melhor do que o esperado.

Todos os palestrantes apresentaram seus temas dentro do horário sem atrasos, houveram muitas perguntas, por sinal todas muito interessantes o que proporcionou um bate papo aberto entre participantes e os palestrantes que participaram das respostas não apenas na apresentação de seus temas e sim de forma geral, foi uma dinâmica muito boa.

Fomos prestigiados pela nossa MVP Lead Fernanda Saraiva que também esteve presente durante a apresentação dos temas.

Ao final do evento foram sorteados os prêmios, inscrições gratuítas para cursos promovidos por mim e pelo Waldyr Félix, além de livros sobre ASP.NET em português.
Foram coletados cerca de 150 kilos de alimentos que foram doados a instituições carentes.

As apresentações e os slides de todas as apresentações estarão disponíveis no site oficial do evento.

O evento foi todo organizado em cerca de um mês e foi a primeira edição de um evento que está programado para ser semestral. Para as próximas edições teremos muito mais novidades.

Gostaria de agradecer a todos os participantes e aos palestrantes que se comprometeram e entregaram ótimas palestras e ao Waldyr Félix que sem seu engajamento e esforço não teria sido possível realizar este evento.

Aguardem pelo próximo em breve. Ate lá!

Links

O Futuro do ASP.NET vNext – MVC 6

Publicado em por

Você já parou para pensar no futuro do ASP.NET daqui alguns anos? O futuro chegou e foi anunciado hoje! Quem acompanha já deve ter reparado no termo OWIN ou lido algo sobre Project Katana / Helios, etc. Hoje uma página de 12 anos foi virada para um novo tempo. Conheça aqui o ASP.NET do Futuro.

ASP.NET vNext

O artigo é extenso e foi utilizada uma linha cronológica para apresentar todo o processo da evolução do ASP.NET.

Um breve olhar no passado do ASP.NET

O ASP.NET desde seu lançamento foi criado originalmente para dois publicos em específico:

  • Desenvolvedores ASP Clássico
  • Desenvolvedores Windows

O resultado não podia ser diferente, a primeira versão do ASP.NET conhecida como Web Forms é uma combinação do desenvolvimento Windows (componentes ricos, desenvolvimento rápido, arrastar e soltar) com a plataforma Web.

Para suportar toda a riqueza de funcionalidades do Web Forms foi necessário implementar muitas classes no .Net Framework, este que por sua vez é mono-bloco, ou seja, muitas funcionalidades estão acopladas em um único assembly, o System.Web (núcleo de objetos HTTP e o próprio framework de WebForms).

Devido a isso o ASP.NET sempre esteve fortemente acoplado ao .Net Framework e dependente de um específico Web host, o Internet Information Services (IIS).

O ASP.NET Web Forms foi a única forma conhecida de ASP.NET durante muitos anos.

Evolução da plataforma ASP.NET e suas dificuldades

Quem desevolve com ASP.NET desde seus primórdios sabe que antigamente era necessário muito tempo (ordem de anos) para que fosse liberada uma nova versão do ASP.NET, e isso nunca foi bom, pois as outras plataformas avançavam muito mais rápido, muitas novas tecnologias surgiam e o ASP.NET precisava se manter competitivo para atender as novas necessidades.

O grande ponto é que o ASP.NET sempre precisou crescer numa velocidade muito maior do que o .NET Framework cresce, porém ambos sempre estiveram muito acoplados através do System.Web que faz parte do .NET Framework, ou seja, muitas vezes para a implementação de um simples recurso no ASP.NET poderia haver algum impacto no .NET Framework e que por sua vez poderia demorar anos até receber a atualização para suporte a tal recurso.

Além do problema do alto acoplamento, por mais que o ASP.NET e o .NET Framework recebessem novas funcionalidades a adoção era demorada demais, o motivo maior é que as empresas não atualizam o .NET Framework de imediato, é necessário todo um processo de validação, revisão de plataforma, homologação e etc, até hoje em 2014 boa parte dos servidores de hospedagem não trabalham com a versão 4.5 do .NET Framework.

O desenvolvedor muitas vezes precisava esperar anos e anos para utilizar um novo recurso da plataforma.

Como resolver isso?

Solução número 1 – Separar

O ASP.NET MVC foi introduzido em 2007-2008 sendo que é distribuido separadamente do ASP.NET clássico, ou seja, isso aumentou a velocidade da entrega de novidades para o ASP.NET as versões do MVC foram entregues como complemento através de novas versões do Visual Studio, via NuGet ou via o aspnetwebstack do ASP.NET, onde é possível utilizar as versões dos build noturnos, código ASP.NET que foi desenvolvido a menos de 24 horas.

Quem desenvolve com ASP.NET há algum tempo vem nos últimos anos presenciando muitas mudanças, além do ASP.NET MVC ainda vieram o Razor, Web API, SignalR, SPA, ASP.NET Identity e todos foram distribuidos separadamente.

Existe a sensação que a Microsoft esta com grande foco em evoluir a plataforma ASP.NET, atualmente em média de a cada seis meses é liberada uma nova versão ou novas funcionalidades / tecnologias agregadas ao ASP.NET. para que ela se mantenha altamente competitiva entre as demais de mercado, e isso já é fato, analisando a produtividade em utilizar ASP.NET com Visual Studio e todas as vantagens que o ASP.NET oferece, fica muito claro o motivo pelo qual cada vez mais empresas e profissionais adotam o ASP.NET como plataforma oficial de desenvolvimento Web.

Para um maior detalhamento assista meu vídeo da palestra Novidades do ASP.NET MVC 5.x

Mesmo com a separação do ASP.NET MVC em relação ao ASP.NET clássico ainda existe uma forte dependência com o System.Web e por sua vez a necessidade de utilizar IIS como única opção de Host.

Quando iniciamos um projeto em ASP.NET MVC, por mais que seja um simples “Olá Mundo!” pode ser que não tenha reparado, mas as dependências com o System.Web estão lá, o System.Web provê suporte a envio de e-mail, controles do Web Forms, sessão e etc… Você não precisa disso? Não importa, vai ter que usar, pois se tirar o System.Web de suas referências seu projeto simplesmente não vai funcionar.

O outro problema é que por mais que o ASP.NET MVC tenha capacidade de ser uma plataforma leve e performática ela sofre uma boa perda devido ao fardo do System.Web que precisa estar presente para fazer o pipeline com o IIS.

Solução número 2 – Quebrar as dependências.

Em 2012-2013 surgiram o ASP.NET SignalR e ASP.NET WebAPI, estes dois componentes ASP.NET não possuem nenhuma dependência com o System.Web, foram desenvolvidos para levar o ASP.NET a um novo patamar, a da independência de plataforma, pois tanto o SignalR como o WebAPI podem rodar em ambientes não Microsoft (Linux/OSx).

Essa foi a quebra da independência ao legado do System.Web, mas até então apenas estes dois componentes podiam rodar independente do IIS, System.Web e Windows.

Foi neste momento que a comunidade técnica conheceu o OWIN.

Apresentando o OWIN

Desde meados de 2009 o ASP.NET se tornou open source e devido a este fato a comunidade técnica pode se juntar ao time de engenheiros da Microsoft para conhecer e implementar melhorias e sugestões. Foram os próprios membros da comunidade técnica que baseando-se no design do Node.js e do Rack da comunidade Ruby, criaram uma especificação chamada OWIN (Open Web Interface for .NET).

O OWIN define uma interface padrão entre servidores Web e aplicações .NET.
O objetivo da interface OWIN é desacoplar o servidor e a aplicação, incentivar a criação de módulos simples para o desenvolvimento em ASP.NET, e, por ser um padrão aberto, estimular o ecossistema open source de ferramentas .NET de desenvolvimento Web.

Resumidamente o OWIN é uma camada de abstração entre o server e a aplicação.

O objetivo do OWIN é que novos componentes possam ser facilmente desenvolvidos e consumidos, porém de forma agnostica, ou seja, que possam rodar em outras plataformas como Unix (Mac/Linux) e que possam ser portados de uma plataforma para outra sem necessidade de recompilação.

  • É um “standart” uma especificação.
  • Não existe exatamente como código ou componente.
  • É a descrição de como idealmente o comportamento de sua implementação deve funcionar.

Katana Project

É uma implementação Microsoft da especificação OWIN no ASP.NET.

A Microsoft apostou na proposta do OWIN e o implementou nos projetos ASP.NET SignalR e ASP.NET WebAPI, essa implementação recebe o nome de Katana Project. Mais tarde o ASP.NET Identity surgiu implementando bibliotecas do Katana Project também.

Além da Microsoft, outros projetos implementam OWIN como NancyFx, FubuMVC, NOWIN etc.

Confira no vídeo abaixo mais detalhes sobre arquitetura OWIN – Katana Project.

Project Helios

A implementação do OWIN atrávés do Katana Project proporcionou a criação de componentes ASP.NET muito mais leves, performáticos, independentes de plataforma e SelfHost, porém caso seja necessário contar com alguns recursos que o Host ASP.NET clássico (IIS) provê, tudo isso fica a cargo do desenvolvedor da aplicação.

O IIS apesar de trabalhar apenas no pipeline do ASP.NET clássico (System.Web) possui uma série de benefícios que nem sempre podem ser deixadas de lado:

  • IIS lida com gerenciamento da vida útil aplicação.
  • Ele pode suspender (em vez de encerrar) processos que estão ociosos para ajudar a equilibrar os recursos disponíveis do sistema.
  • IIS oferece um cache de modo de usuário embutido e pode comprimir automaticamente o conteúdo dos responses se for o caso.
  • IIS suporta filtragem de requests e transient worker process identities.
  • Mais de 10 anos de implementações e melhorias de segurança.
  • No cenário do Self Host você é responsável por muitas das responsabilidades que o IIS toma conta, além disso ele já existe para isso por que não utilizá-lo?

São esses os motivadores do Project Helios, porém devido à necessidade do IIS trabalhar no pipeline no System.Web muita performance seria perdida, por isso o Project Helios trabalha apenas com o “Core” do IIS o utilizando como uma espécie de API, o “Core” do IIS é extremamente rápido e poderoso, pois disponibiliza apenas as suas funcionalidades sem depender do pipeline do ASP.NET clássico (System.Web).

O Project Helios oferece suporte aos projetos desenvolvidos em Katana (OWIN), porém não é dependente dele para ser utilizado, é possível desenvolver uma aplicação baseada apenas em Project Helios que rodará apenas no padrão IIS e não terá opções de SelfHost e multiplataforma, em uma arquitetura de aplicações para Windows pode ser muito vantajoso, pois é pelo menos 96% mais rápido que o ASP.NET clássico. Na demo exibida no vídeo abaixo o resultado foi quase 6x mais rápido utilizando Helios.

Requerimentos mínimos para utilização do Project Helios

  • Windows 8 ou Windows Server 2012
  • .NET Framework 4.5.1
  • Visual Studio 2012 ou 2013

Resumo Cronológico

O ASP.NET desde seu lançamento sofreu com a grande demora de liberações de novas versões, algumas plataformas novas surgiram e passaram a frente devido uma evolução mais rápida, com a implementação do ASP.NET MVC esse tempo de liberações diminuiu, porém a plataforma ainda era limitada em relação às outras devido a herança historica do Web Forms (System.Web) em seu pipeline, impedindo que algumas melhorias fossem implementadas.

Com o surgimento do OWIN e os projetos Katana e Helios novas frentes se abriram e a engenharia do time de ASP.NET começou a trabalhar em uma nova versão, a maior e melhor mudança do ASP.NET em todo o seu período de existência, hoje o futuro chegou.

ASP.NET vNext – MVC 6

Foi anunciado dia 13/05 durante uma sessão do TechEd North America 2014 a nova versão do ASP.NET chamada vNext e que vai mudar tudo o que você sabe sobre ASP.NET, é um novo paradigma, um novo stack, tudo que os desenvolvedores Web mais maduros sabiam que era possível e torciam para que um dia fosse feito.

Todos os nomes que vimos como Katana, Helios e ASP.NET vNext provavelmente irão mudar, são nomes dados para projetos em execução, na versão final ganham um outro nome mais familiar.

Você desenvolvedor ASP.NET veterano, levante agora da cadeira e aplauda, você está diante a maior mudança do ASP.NET em seus 12 anos de existência. Você iniciante ASP.NET nem pense em Web Forms, caia direto nesse stack e comece a entender tudo como funciona daqui pra frente.

O que mudou

  • Web Pages, MVC, Web API agora é uma coisa só, chamado de MVC 6
  • Novas versões otimizadas para nuvem do MVC 6, SignalR 3 e Entity Framework 7
  • Acabou a dependência do System.Web, MVC 6 agora é um middleware, leve e performático, agora apenas o Web Forms depende (para sempre) do System.Web.
  • Versões otimizadas para nuvem do MVC, Web API, Web Pages, SignalR e Entity Framework.
  • Maior portabilidade, não existe dependência de assemblies do GAC facilitando o deploy em nuvem e em ambientes não Windows (Linux/OSx/Etc)
  • Possibilidade de hospedar sua aplicação no IIS ou em um processo self hosted
  • Injeção de dependência nativa dentro do framework
  • Suporte ao legado do Web Forms, MVC 5, Web API 2, Web Page 3 , SignalR 2 e EF 6
  • Deploy do runtime e framework com a sua aplicação, possibilitando rodar lado a lado 2 versões diferentes do framework
  • Arquivo project.json irá integrar o arquivo de projeto (.csproj), o packages.config e o Nuget specifications (nuspec);
  • Suporte ao Rosyln, ou seja, não precisa mais parar a aplicação para alterar uma classe, basta alterar salvar e dar F5 no browser, pronto! Muita produtividade!
  • Tudo é entrege via NuGet até o runtime!
  • Mais open source que nunca (foi para o GitHub) e faz parte do .Net Foundation.
  • Baixissimo consumo de memória
  • Completamente Multiplataforma!!! Rode ASP.NET onde quiser!

Veja alguns screenshots

Assista ao vídeo da palestra – O Futuro do ASP.NET + Novidades do vNext – MVC 6

Acompanhe os slides da palestra

Assista esse vídeo exibindo como rodar a nova versão do ASP.NET vNext – MVC 6

Bons estudos!!!

Referências

Vamos continuar a troca de conhecimentos, escreva seu comentário abaixo 😉

Visual Studio Summit 2014 – Novidades do ASP.NET MVC 5.x – Palestra + Vídeo

Publicado em por

No sábado dia 26/04/14 aconteceu a terceira edição do Visual Studio Summit, um evento que eu participo como organizador e palestrante.

Sobre o Visual Studio Summit 2014

O Visual Studio Summit é o maior evento de desenvolvedores Microsoft do Brasil, ocorre pelo terceiro ano consecutivo na Sede da Microsoft Brasil na capital de São Paulo.

Eu tenho um grande prazer de atuar na organização deste evento ao lado do mestre Ramon Durães, meses antes do evento nós já estamos trabalhando para oferecer a melhor experiência possível para toda a comunidade técnica.

Alguns números sobre o evento

  • Palestrantes: 28
  • Staff apoio operação: 8
  • Palestras: 79 palestras 
  • Total de horas de conteúdo: 39.5 horas  
  • Salas: 6 simultâneas e 3 salas Ask the Expert.

Minha Palestra

A palestra apresentada nesta edição foi “Novidades do ASP.NET MVC 5.x” onde eu abordei todas as atualizações desde a versão do ASP.NET MVC 5.

Como a versão do Visual Studio Summit 2014 não foi gravada eu fiz questão de regravar minha palestra em casa e disponibilizar para quem não viu ou quer ver de novo, só que agora com 1h00 de duração e mais detalhes no conteúdo.

Segue minha apresentação de slides também para acompanhar o tema

Durante o lançamento da versão do ASP.NET MVC 5 eu escrevi alguns artigos relacionados

Gostaria de agradecer a todos presentes, palestrantes e staffs, especialmente o time de MSP’s e MTACs que foram indicados pela Microsoft para apoiar a realização do evento. Todos foram muito prestativos, educados e dedicados. Parabéns a vocês!

Aguardo você na próxima edição 😀

Links para seguir

ASP.NET BRASIL CONFERENCE – São Paulo

Publicado em por

O grupo ASP.NET BRASIL qual faço parte e atuo no time de líderes está organizando um evento épico sobre ASP.NET no dia 10/05, um formato inédito, 6 MVPs de ASP.NET dividindo o mesmo palco no mesmo dia, confira como participar.

ASP.NET BRASILO Grupo ASP.NET BRASIL em comemoração pelos seus mais de 1.000 participantes ativos realizará este evento gratuíto, e para falar de ASP.NET nada melhor do que reunir 6 MVPs de ASP.NET não acham?

Horário Palestrante Tema
08:00 – 09:00 Credenciamento  
09:00 – 09:30 Abertura  
09:30 – 10:20 Alexandre Tarifa (MVP) Construindo sites Mobile com ASP.NET
10:30 – 11:20 André Baltieri (MVP) Desenvolvendo APIs RESTful com Web API
11:30 – 12:20 Eduardo Pires (MVP) O Futuro do ASP.NET
12:30 – 14:00 Almoço  
14:00 – 14:50 Fabrício Sanchez (MVP) Breve
15:00 – 15:50 Victor Cavalcante (MVP) ASP.NET Identity o substituto do Membership
16:00 – 16:50 Waldyr Félix (MVP) Novidades do ASP.NET MVC 5.X
17:00 – 18:00 Encerramento Sorteio de Prêmios

Para participar basta levar 1kg de alimento não-perecível que será doado para instituições carentes.

10 de Maio – Sábado – PUC-SP – Departamento de Computação
Rua Marquês de Paranaguá 111 – Consolação – 01303-050

Faça sua inscrição e divulgue para seus conhecidos
https://www.sympla.com.br/aspnet-brasil-conference—sao-paulo—presencial__19070 

Site do Evento
http://aspnetbrasil.azurewebsites.net/ 

Inscreva-se no grupo ASP.NET BRASIL
https://www.facebook.com/groups/aspnetmvcbr

Sorteio de Prêmios

Serão sorteadas duas inscrições gratuítas para os cursos:

Os prêmios serão sorteados apenas para os cadastrados pelo site e que estiverem presentes até o final do evento.

Comprovante de Participação

Todos os presentes receberão comprovante de participação eletrônico que será enviado por e-mail.

Inscrição Rápida

As vagas são limitadas, por favor, em caso de desistência realize o cancelamento via site ou nos comunique sobre o cancelamento da inscrição.

*Grade sujeita à mudanças.

ASP.NET Identity – Nome de usuário no formato de e-mail.

Publicado em por

O ASP.NET Identity é altamente customizável, pois foi desenvolvido justamente para ser adaptado em diversos cenários, nesse artigo iremos implementar como permitir que o nome de usuário esteja no formato de e-mail.

 

ASP.NET Identity

Muitos portais e sistemas Web optam por utilizar o próprio e-mail do usuário registrado como nome de usuário, isso proporciona algumas vantagens:

  • Um username a menos para o usuário decorar.
  • Estimula o usuário fornecer um e-mail real.
  • O usuário não precisa se chatear por que seu username escolhido já esta em uso.
  • Usuários não mudam de e-mail com tanta frequência.
  • Um campo a menos para o usuário preencher no cadastro.
  • Os maiores portais utilizam e-mail como username (Facebook, Microsoft, Google, Linkedin, etc…)

Por padrão o ASP.NET Identity não permite que o username possua caracteres especiais, logo o “@” não será permitido, para permitir que o usuário utilize seu e-mail como username será necessário realizar as mudanças a seguir.

*O exemplo a seguir está com base no projeto utilizado no artigo anterior sobre ASP.NET Identity

Método 1

Esse é o método mais rápido de implementar que é desabilitando a validação de caracteres especiais da classe UserManager, é simples e rápido, localize o arquivo Controllers > AccountController.cs, o construtor da controller estará como no código a seguir.

public AccountController(UserManager userManager)
{
    UserManager = userManager;
}

Nesse caso basta criar um novo UserValidator qual possui a propriedade AllowOnlyAlphanumericUserNames que ao ser setada como false permite que outros caracteres sejam utilizados no nome de usuário.

public AccountController(UserManager userManager)
{
    UserManager = userManager;

    // Criando um UserValidator
    UserManager.UserValidator = new UserValidator(UserManager)
    {
        // Desabilitando a regra de apenas caracteres alfanumericos.
        AllowOnlyAlphanumericUserNames = false
    };
}

É funcional mas eu pessoalmente não acho nada elegante.

Método 2

Uma opção mais complexa é criar seu próprio CustomValidator para ser utilizado no momento da validação do username. Para isso sugiro que seja criada uma pasta específica chamada Validators por ex. Nesta pasta crie uma classe chamada CustomUserValidator.cs e utilize o código a seguir.

using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
using Microsoft.AspNet.Identity;

namespace DemoIdentity.Validator
{
    public class CustomUserValidator<TUser> : IIdentityValidator<TUser>
        where TUser : class, IUser
    {
        private static readonly Regex EmailRegex = new Regex(@"^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}$", RegexOptions.Compiled | RegexOptions.IgnoreCase);
        private readonly UserManager<TUser> _manager;

        public CustomUserValidator()
        {
        }

        public CustomUserValidator(UserManager<TUser> manager)
        {
            _manager = manager;
        }

        public async Task<IdentityResult> ValidateAsync(TUser item)
        {
            var errors = new List<string>();
            if (!EmailRegex.IsMatch(item.UserName))
                errors.Add("O endereço de email não é válido.");

            if (_manager != null)
            {
                var otherAccount = await _manager.FindByNameAsync(item.UserName);
                if (otherAccount != null && otherAccount.Id != item.Id)
                    errors.Add("Já existe uma conta utilizando este email, selecione um diferente.");
            }

            return errors.Any()
                ? IdentityResult.Failed(errors.ToArray())
                : IdentityResult.Success;
        }
    }
}

Note que a validação de formato de e-mail é feita através de expressão regular e a classe de validação também verifica se o e-mail já não está cadastrado na base, caso qualquer erro seja encontrado uma mensagem de erro é adicionada à uma lista de mensagens e no final é repassada para o helper Failed da classe IdentityResult.

Para implementar a classe CustomUserValidator basta modificar o construtor da controller AccountController da mesma forma que foi feito no método 1.

public AccountController(UserManager<ApplicationUser> userManager)
{
    UserManager = userManager;

    // Aplicando um UserValidator customizado.
    UserManager.UserValidator = new CustomUserValidator<ApplicationUser>(UserManager);
}

Notem que a classe UserManager que é exposta pelo ASP.NET Identity permite que você utilize uma classe de validação que implemente a interface IIdentityValidator e esta classe pode ser customizada para atender qualquer regra que sua validação exigir.

Desta forma além de mais elegante é possível realizar diversas validações em uma classe exclusivamente responsável por validar o nome de usuário.

Caso esteja utilizando o exemplo iniciado no artigo anterior basta realizar as modificações a seguir.

  1. Remover a propriedade “Email” das classes/arquivos
    • ApplicationUser
    • RegisterViewModel
    • View Account
    • AccountController (método Register)
  2. Utilizar o DataAnnotation [Email] na propriedade UserName da classe RegisterViewModel
  3. Atualizar o banco de dados (usando migrations por ex).

Referências

Este artigo faz parte da série de como customizar diversas funcionalidades no ASP.NET Identity. Aguarde pelos próximos.

Ficou com dúvidas? Quer compartilhar conosco alguma experiência? Utilize os comentários abaixo 😉

Até a próxima.