Israel Aéce

Projetando.NET não existe mais

Israel Aéce — Wed, 22 Apr 2009 06:28:00 GMT

Há alguns anos eu mantenho um site chamado Projetando.NET: http://www.projetando.net. Além deste site, eu também mantenho um blog na comunidade portuguesa PontoNetPt, que criei logo no ínicio da mesma. De acordo com as minhas regras, posts que não rendem artigos eram publicados neste blog e matérias maiores e mais detalhadas eu optava por publicá-los no Projetando.NET.

Como eu não investi muito tempo no desenvolvimento do site do Projetando.NET, eu decidi então optar por uma solução pronta para a publicação e gerenciar os meus posts e artigos, ao invés de evoluir o projeto atual. Com isso, eu resolvi criar um novo domínio que é http://www.israelaece.com e migrar todos os meus posts deste blog e também os artigos do site Projetando.NET para lá. Se tentar acessar o Projetando.NET, apenas terá uma página estática, informando que o site foi mudado para http://www.israelaece.com. Se estiver a procura de um artigo, consulte a opção de busca deste novo site e, se mesmo assim não encontrá-lo, entre em contato comigo que poderia ajudá-lo. As minhas contas de e-mail israel@projetando.net e contact@projetando.net também deixam de existir. O meu novo e-mail agora passa a ser ia@israelaece.com.

Peço também que atualizem o endereço de RSS, que agora passará a conter os posts e artigos. O novo endereço é http://www.israelaece.com/syndication.axd. Para que fique claro, este novo site destina-se exclusivamente a publicação de conteúdo técnico e não pessoal, como já acontecia antes.

É importante ficar claro que estou deixando a PontoNetPt apenas por uma questão de comodidade. Em nenhum momento os integrantes deste time me deixaram sem suporte. A PontoNetPt continuará evoluindo, assim como o Nuno Gomes publicou neste post. Quero publicamente agradecer ao time da PontoNetPt, mais precisamente ao João Paulo Carreiro, Ricardo Figueira, João Cardoso, Luis Abreu e Paulo Morgado, que sempre me ajudaram em tudo que precisei, tanto em relação ao meu blog quanto em conselhos para a minha vida profissional.

Otimizando a compilação

Israel Aéce — Thu, 16 Apr 2009 16:33:00 GMT

Quando fazemos alguma mudança no diretório bin, App_Code ou no arquivo Global.asax, toda a aplicação ASP.NET será recompilada. Para sites pequenos, isso não tem muitos problemas, já que não há muitos arquivos/recursos a serem compilados. Já quando temos um site com várias páginas, esse processo pode se tornar muito lento, principalmente na primeira requisição, que é o onde a compilação irá ocorrer.

O SP1 do .NET Framework 3.5 inclui um novo atributo chamado optimizeCompilations, dentro do elemento compilation. Quando esse atributo estiver definido como False (configuração padrão), qualquer mudança provocará a recompilação total do site; já quando voce, explicitamente, definí-lo como True, somente os arquivos afetados pela mudança serão recompilados. Abaixo temos o exemplo da utilização deste novo atributo:

<compilation optimizeCompilations="true">

WSDL com nome da máquina

Israel Aéce — Wed, 15 Apr 2009 05:31:00 GMT

Quando publicamos um serviço WCF em um servidor, mais precisamente, dentro do IIS, é comum aparecer o nome da máquina no endereço de acesso ao documento que descreve o serviço (WSDL). Como se isso não bastasse, dentro do WSDL ainda existem diversos outros links, que também utilizam o nome da máquina para compor o endereço. Mas o correto seria aparecer o nome do domínio ou, até mesmo, o IP do servidor onde o serviço está hospedado.

Isso ocorre porque o WCF utiliza as configurações do IIS (binding information) para determinar o base address do serviço. Para resolver isso, podemos atualizar as configurações do IIS. Caso esteja utilizando o IIS 6.0, então pode adicionar um host header customizado nas configurações do Web Site, ou ainda, através do seguinte comando:

C:\WINDOWS\system32\>cscript.exe %systemdrive%\inetpub\adminscripts\adsutil.vbs set w3svc/<ID do Web Site>/ServerBindings ":80:www.dominio.com.br"

Se estiver utilizando o IIS 7.0, pode recorrer a configuração do arquivo applicationHost.config, assim como é mostrado abaixo:

<bindings>
<binding protocol="http" bindingInformation="*:80:www.dominio.com.br" />
</bindings>

E, finalmente, se já estiver utilizando o .NET Framework 3.5 SP 1, então pode utilizar o elemento baseAddressPrefixFilters, assim como é mostrado neste post.

Strong Name Bypass

Israel Aéce — Tue, 31 Mar 2009 17:03:00 GMT

Um dos passos necessários durante a carga do Assembly é análise da assinatura do Strong Name. Independentemente do Code Access Security, essa análise sempre é realizada e muitas aplicações pagam esse preço sem ao menos utilizá-lo. A partir do SP1 do .NET Framework 3.5, a Microsoft incluiu uma funcionalidade chamada de Strong Name Bypass, não mais fazendo essa verificação e, consequentemente, tendo um ganho de performance durante a sua inicialização.

Essa análise não será mais realizada para Assemblies que são carregados em um ambiente full-trusted. Obviamente que essa análise acontecerá quando, para computar a segurança, voce levar em consideração o Strong Name. Se, por algum motivo, voce quiser reabilitar a verificação, então pode recorrer ao elemento bypassTrustedAppStrongNames, definindo o atributo enabled para false, assim como é mostrado abaixo, utilizando o arquivo de configuração:

<configuration>
    <runtime>
        <bypassTrustedAppStrongNames enabled="false"/>
    </runtime>
</configuration>

Core Services no ASP.NET 4.0

Israel Aéce — Tue, 24 Mar 2009 17:28:00 GMT

Além de algumas novidades que já foram reportadas neste post, o ASP.NET 4.0 trará ainda uma série de funcionalidades muito interessantes e, entre elas, teremos:

OutputCaching Extensível

Quando utilizamos o OutputCaching em uma página, a primeira requisição a executará, e antes de devolver o conteúdo para o cliente, o resultado é armazenado na memória do servidor Web, e com isso, futuras requisições utilizarão esse conteúdo ao invés de reprocessar a página completamente. O ASP.NET 4.0 fornece uma forma altamente flexível para conseguirmos customizar o repositório de caching trabalhando com providers, assim como já acontece nas principais funcionalidades do ASP.NET atual.

Auto-Start de Aplicações

Todos sabemos que as aplicações ASP.NET tem um delay na primeira requisição, que se deve ao fato de efetuar a compilação da mesma. A partir do ASP.NET 4.0, em conjunto com o IIS 7.5, teremos uma funcionalidade chamada de auto-start. Ao configurar esta funcionalidade em uma aplicação, o IIS enviará uma mensagem ao ASP.NET para que a sua aplicação faça o processo necessário para deixá-la pronta para ser consumida. Tudo isso ocorre no momento em que o IIS/AppPool ainda não aceita requisições.

O mais interessante é que ainda podemos interceptar este evento, implementando o método Preload da Interface IProcessHostPreloadClient. Nele podemos fazer outras "pré-inicializações" que antes eram feitas sob demanda.

Redirecionamento Permanente

Como já comentado aqui, agora teremos um método chamado RedirectPermanent que efetuará esse tipo de redirecionamento.

Compressão das variáveis de Sessão

Quando utilizamos variáveis de sessão, elas são armazenadas na memória do servidor onde a aplicação está sendo executada (In-Process). Além disso, temos duas outras possibilidades que é o armazenamento diretamente no SQL Server ou um servidor exclusivo para o armazenamento das variáveis sessão (Out-of-Process). Nestas duas últimas opções, há um overhead extra, que ocorre justamente porque o objeto responsável que armazena as informações, deverá ser serializado antes de enviado para o destino remoto.

Dependendo do que é armazenado dentro das variáveis de sessão, esse processo pode custar muito caro, tanto em termos de comunicação quanto em termos de memória ou espaço físico. A partir do ASP.NET 4.0, o elemento sessionState irá possuir um novo atributo chamado compressionEnabled. Ao definí-lo como True, o ASP.NET fará o processo necessário para comprimir e descomprimir os dados, utilizando a classe GZipStream.

Para aqueles que quiserem mais informações sobre as novas funcionalidades, consulte este documento.

Configurando o limite de conexões pendentes

Israel Aéce — Tue, 24 Mar 2009 07:31:00 GMT

Quando expomos um serviço através do binding NetTcpBinding, as requisições que chegam até ele, são processadas e, finalmente o retorno é enviado para o respectivo cliente. As mensagens que chegam são processadas no formato FIFO (first-in, first out), ou seja, elas aguardam o processamento em uma fila e, sob demanda, são encaminhadas para o processamento.

Se a velocidade do processamento da mensagem é mais lenta que a velocidade de envio das mensagens, essa fila pode aumentar. Por padrão o binding NetTcpBinding limita, através da propriedade ListenBacklog, o número de requisições pendentes que podem ser enfileiradas. O valor padrão é 10 e, dependendo da quantidade de requisições que chegam para o serviço, esse limite pode exceder e, a seguinte exceção será disparada:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://localhost:8879/srv. The connection attempt lasted for a time span of 00:00:02.1404880. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:8879. ---> System.Net.Sockets.SocketException:No connection could be made because the target machine actively refused it 127.0.0.1:8879

A alternativa aqui é aumentar esse número, definindo um valor próximo a quantidade das conexões simultaneas que eventualmente podem chegar para o serviço. O exemplo abaixo ilustra a configuração desta propriedade no binding NetTcpBinding:

host.AddServiceEndpoint(typeof(IContrato), new NetTcpBinding() { ListenBacklog = 70 }, "srv");

Serialização de Propriedades Automáticas

Israel Aéce — Tue, 17 Mar 2009 20:39:00 GMT

Quando queremos expor uma propriedade, na maioria das vezes existe um campo privado que serve como "repositório" para a informação que é definida ou lida. A propriedade tem o papel de interceptar a leitura e escrita à este campo privado através de blocos get/set.

Para reduzir o trabalho, a partir da versão 3.0 do C#, é disponibilizado uma funcionalidade chamada de Automatic Properties que, por sua vez, nos permite omitir a criação deste campo privado. Na realidade, essa funcionalidade nada mais é do que "açúcar sintático", já que no momento da compilação, o C# irá injetar o campo privado para armazenar a informação que a propriedade expõe. Como exemplo, imagine que voce cria uma classe com a seguinte definição:

public class Usuario
{
    public string Nome { get; set; }
}

No momento da compilação, ela será definida como:

public class Usuario
{
    [CompilerGenerated]
    private string <Nome>k__BackingField;

    public string Nome
    {
        [CompilerGenerated]
        get
        {
            return this.<Nome>k__BackingField;
        }
        [CompilerGenerated]
        set
        {
            this.<Nome>k__BackingField = value;
        }
    }
}

Já vi alguns casos em que esses objetos que fazem uso desta técnica, são marcados com o atributo SerializableAttribute e, como o próprio atributo indica, permitir a serialização do mesmo. Quando um objeto com essas características são expostos através de serviços WCF (talvez quando voce já possuir uma API com essas classes definidas), precisamos de alguns cuidados especiais.

O serializador padrão do WCF é o DataContractSerializer. Esse serializador trabalha em conjunto com os atributos DataContractAttribute e DataMemberAttribute, serializando as propriedades ou campos públicos que são decorados com um desses dois atributos. Esse serializador também suporta classes decoradas com o atributo SerializableAttribute mas, como esse atributo foi desenhado para persistir e reconstituir na íntegra a representação do objeto, todos os campos (privados ou públicos) são serializados. As propriedades aqui são ignoradas.

Ao submeter um objeto com as características que vimos acima para o serializador padrão do WCF, ele persistirá os campos privados, que no nosso caso é o <Nome>k__BackingField, e que na maioria dos casos, não é isso que desejamos. Como exemplo, podemos utilizar o seguinte código para analisar o resultado deste processo:

new DataContractSerializer(typeof(Usuario))
    .WriteObject(
        File.Create("Usuario.xml"),
        new Usuario() { Nome = "Israel" });

Abaixo temos conteúdo Xml correspondente:

<Usuario xmlns="..." xmlns:i="...">
<_x003C_Nome_x003E_k__BackingField>Israel</_x003C_Nome_x003E_k__BackingField>
</Usuario>

Caso voce não possa alterar os atributos que já foram definidos para a classe, uma possibilidade que temos é utilizar o serializador XmlSerializer. Ao contrário do DataContractSerializer, esta classe irá serializar somente as propriedades ou campos públicos. Assim como o exemplo acima, para efetuarmos este teste, podemos utilizar o seguinte código:

new XmlSerializer(typeof(Usuario))
    .Serialize(
        File.Create("Usuario.xml"),
        new Usuario() { Nome = "Israel" });

E, finalmente, o resultado em Xml:

<?xml version="1.0"?>
<Usuario xmlns:xsi="..." xmlns:xsd="...">
<Nome>Israel</Nome>
</Usuario>

O XmlSerializer é utilizado também pelo ASP.NET Web Services (ASMX). Por mais que esta técnica funcione, antes de alterar o serializador padrão do WCF, é importante que voce analise as vantagens e desvantagens da sua utilização e, para isso, poderá recorrer à própria documentação.

ASP.NET Development Server parou de funcionar

Israel Aéce — Sat, 14 Mar 2009 02:45:00 GMT

Com a instalação de uma atualização que a Microsoft lliberou, o arquivo hosts (C:\Windows\System32\drivers\etc) pode ter sido alterado, removendo a entrada que tem o apontamento do IP 127.0.0.1 para localhost, fazendo com que os projetos ASP.NET que usam o servidor interno do Visual Studio .NET para hospedar as aplicações deixem de funcionar. Com isso, ao rodar essas aplicações, voce receberá a seguinte mensagem: "Internet Explorer cannot display the webpage".

Como já era de se esperar, basta readicionar esta linha no arquivo para que tudo volte ao normal, assim como é mostrado abaixo:

127.0.0.1 localhost

Compartilhando portas através do protocolo TCP

Israel Aéce — Fri, 13 Mar 2009 18:46:00 GMT

Ao criar um serviço WCF, podemos disponibilizá-lo através do protocolo TCP (net.tcp), utilizando uma porta específica. Uma vez que voce publica esse serviço, nenhum outro serviço naquela mesma máquina poderá utilizar aquela porta ao mesmo tempo, e se fizer isso, uma exceção do tipo AddressAlreadyInUseException será disparada exibindo a seguinte mensagem: There is already a listener on IP endpoint [MachineName]:[Port]. Make sure that you are not trying to use this endpoint multiple times in your application and that there are no other applications listening on this endpoint.

Podemos não perceber mas o Windows permite o compartilhamento de uma mesma porta TCP para expor múltiplas aplicações. Um exemplo disso é o HTTP, que permite múltiplas aplicações estarem acessíveis através da porta 80 do protocolo TCP. Isso é possível graças à um listener (HTTP.SYS) que o IIS possue e que, baseando-se no conteúdo da mensagem, encaminha a requisição para a aplicação correspondente processá-la.

Ao instalar o .NET Framework, um serviço chamado Net.Tcp Port Sharing Service é instalado no Windows, dando a possibilidade de múltiplos serviços WCF compartilharem a mesma porta TCP, assim como o HTTP. Esse serviço (hospedado através do processo SMSvcHost.exe (C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation)) tem a finalidade de inspecionar a mensagem, extrair o endereço de destino, e baseando-se nele, encaminhar a requisição para a aplicação que a processará.

Além deste serviço funcionando, ainda é necessário uma pequena configuração no código que expõe serviço WCF. O binding NetTcpBinding possui uma propriedade booleana chamada PortSharingEnabled que, por padrão, é definida como False. Voce deverá definí-la como True para todos os serviços que desejarem compartilhar uma porta TCP específica. Ao fazer isso, o WCF se encarrega de iniciar automaticamente o serviço Net.Tcp Port Sharing Service, mas voce pode fazer isso manualmente, ou ainda alterar a configuração do serviço para ele ser inciado automaticamente quando o sistema operacional entrar no ar. O trecho de código abaixo ilustra como podemos proceder para configurar o endpoint com o binding e habilitando o compartilhamento da porta TCP:

host.AddServiceEndpoint(
    typeof(IContrato),
    new NetTcpBinding() { PortSharingEnabled = true },
    new Uri("net.tcp://localhost:7373/NomeDoServico/Cadastro"));

Como os serviços irão compartilhar a mesma porta, a distinção da aplicação é determinada pela URI como um todo, ou seja, o que vem depois da porta na URI do serviço precisa ser diferente entre os serviços, caso contrário voce terá o mesmo problema que antes.

Com esta técnica, vamos permitir múltiplas aplicações coexistirem fisicamente na mesma máquina, mas em processos separados, compartilhando a mesma infraestrutura de rede, melhorando a segurança, já que podemos diminiur a superfície de ataque não exigindo a abertura de portas no firewall de forma aleatória.

Melhorando a performance no ThreadPool

Israel Aéce — Wed, 11 Mar 2009 06:16:00 GMT

Como já sabemos, a classe ThreadPool disponibiliza um repositório de threads que podemos utilizar em nossas aplicações, delegando a ela uma tarefa para ser executada através de um delegate. Para isso, é muito comum utilizarmos o método QueueUserWorkItem para enfileirar uma nova tarefa. O exemplo abaixo ilustra a sua utilização em uma aplicação qualquer:

ThreadPool.QueueUserWorkItem(state =>
{
    Console.WriteLine(new StreamReader(@"C:\Temp\Arquivo.txt").ReadToEnd());
});

Quando utilizamos o método QueueUserWorkItem, antes de enfileirar a tarefa a ser executada, ele captura todas as permissões que foram concedidas e, antes de executá-la, essas permissões são aplicadas a thread que está associada à tarefa. Com isso, se a tarefa que voce está tentando executar de forma assíncrona exigir alguma permissão e ela não foi concedida, uma exceção do tipo SecurityException será disparada. Podemos notar esse comportamento com o seguinte código:

new FileIOPermission(FileIOPermissionAccess.Read, @"C:\Temp\Arquivo.txt").Deny();

ThreadPool.QueueUserWorkItem(state =>
{
    Console.WriteLine(new StreamReader(@"C:\Temp\Arquivo.txt").ReadToEnd());
});

No código acima, a aplicação não possui permissão de acesso ao arquivo, e ao executar o método QueueUserWorkItem, a tarefa vinculada também não conseguirá executar a leitura do arquivo, disparando uma exceção. Por menor que seja, utilizar este método sempre tem o overhead para a cópia das permissões atuais e associá-las a thread responsável pela tarefa, para que ela execute no mesmo contexto de segurança.

É justamente neste ponto que entra em cena o método UnsafeQueueUserWorkItem, também da classe ThreadPool. Ao contrário do método QueueUserWorkItem, ele não propaga as permissões para a worker thread, diminuindo o trabalho a ser realizado quando voce enfileira uma nova tarefa ao ThreadPool. A utilização em relação ao que vimos acima muda ligeiramente:

new FileIOPermission(FileIOPermissionAccess.Read, @"C:\Temp\Arquivo.txt").Deny();

ThreadPool.UnsafeQueueUserWorkItem(state =>
{
    Console.WriteLine(new StreamReader(@"C:\Temp\Arquivo.txt").ReadToEnd());
}, null);

Como as permissões não são propagadas e avaliadas com o método UnsafeQueueUserWorkItem, mesmo que a aplicação não tenha as devidas permissões, a execução da tarefa ocorre sem maiores problemas.

É importante dizer aqui que a performance é melhorada mas, em contrapartida, a segurança fica vulnerável. Utilizar este tipo de código pode abrir portas para algum código malicioso, que pode utilizá-lo para elevar os privilégios de uma aplicação e, consequentemente, executar tarefas que atualmente ela não tem permissão. Opte sempre por utilizar esta técnica em uma tarefa em que voce não dependerá de nenhum recurso do sistema operacional (sistema de arquivos, registry, SQL Server, etc.), utilizando em conjunto com tarefas que dependam exclusivamente do processador, como é o caso de cálculos complexos, geração de algum conteúdo, etc., melhorando consideravelmente a performance na execução, sem abrir potenciais problemas de segurança.

IgnoreDataMemberAttribute

Israel Aéce — Tue, 10 Mar 2009 21:50:00 GMT

A partir do .NET Framework 3.5 SP1 temos a possibilidade de suportar a serialização de tipos complexos em serviços WCF, mesmo que eles não estejam decorados com o atributo DataContractAttribute, DataMemberAttribute ou SerializableAttribute, permitindo o suporte à objetos POCO.

Quando trabalhamos nesta linha, não precisamos nos preocupar com os atributos já que, por padrão, todas as propriedades públicas serão serializadas. Já que o comportamento padrão faz com que todas as propriedades serão serializadas, como podemos determinar que uma delas não deve ser disponibilizada para os consumidores do serviço? Neste caso, temos que explicitamente dizer ao runtime do WCF para não serializar tal propriedade e, para isso, recorremos à utilização do atributo IgnoreDataMemberAttribute, contida no namespace System.Runtimem.Serialization, aplicando-o nas propriedades que não queremos que esteja disponível, assim como é mostrado abaixo:

public class Usuario
{
    public string Nome { get; set; }

    [IgnoreDataMember]
    public string Password { get; set; }
}

DBAuthorization – Parte 10 – Conclusão

Israel Aéce — Mon, 09 Mar 2009 23:35:00 GMT

Finalmente chegamos na conclusão desta série. A partir deste momento você tem todas as políticas de acesso as páginas dentro do banco de dados, com uma arquitetura flexível e que pode ser estendida para ser suportada por outros repositórios.

Uma vez que o provider foi criado, sempre que nós precisamos das informações, seja para aplicar a autorização durante a execução ou pelas telas de gerenciamento das informações, sempre utilizamos o provider para isso (classe DBAuthorization), o que torna a aplicação e a API totalmente independente de qual fonte de dados estamos utilizando para armazenar essas informações.

É importante dizer também que, assim como a UrlAuthorization, a DBAuthorization avalia as permissões de forma sequencial, ou seja, a ordem em que elas aparecerem cadastradas no banco de dados será a ordem de avaliação durante a execução. Neste momento não temos nenhuma forma de reordenação dos registros, mas isso pode ser facilmente implementado. Um boa prática aqui é sempre você ir cadastrando em uma ordem coerente, ou seja, negue o acesso anônimo para um diretório como um todo mas, dentro dele, customize o acesso à algumas seções de acordo com os papéis.

Outra semelhança que o DBAuthorizationModule possui em relação ao UrlAuthorizationModule é que faz uso da propriedade User da classe HttpContext. Essa propriedade retorna a instância de uma classe que implementa a interface IPrincipal e, independentemente do tipo de autenticação que está utilizando (Forms (GenericPrincipal) ou Windows (WindowsPrincipal)), ele sempre irá trabalhar de forma genérica. Utilizará a propriedade IIdentity para determinar o nome do usuário e o método IsInRole para avaliar se o usuário faz ou não parte de um determinado papel/grupo.

Para efeitos de centralização e reusabilidade da API, você pode instalar essa DLL dentro do GAC (Global Assembly Cache) e registrar a seção “dbAuthorization” no arquivo machine.config. Esta técnica evitará com que todas as aplicações que desejam fazer uso deste recurso, não precisem explicitamente fazer o registro.

Para finalizar, todo esse projeto não foi implementando em um ambiente real. Os testes foram locais e, se desejar colocá-lo em um ambiente de produção, chamo a atenção para que você refaça os testes, analisando todas as possibilidades necessárias para garantir o bom funcionamento dele.

Quero também agradecer imensamente ao Luis Abreu, expert em tecnologias Microsoft, que revisou e me deu dicas extremamente importantes para ajudar na elaboração desta série. O código para download está no seguinte endereço: http://www.projetando.net/Temp/Posts/DBAuthorization.zip

DBAuthorization – Parte 9 – Interface de Administração

Israel Aéce — Fri, 06 Mar 2009 15:42:00 GMT

Nos posts anteriores analisamos detalhadamente como devemos proceder para criar a infraestrutura necessária, e para efetuar a autorização com as informações armazenadas em uma base de dados. Sem telas de administração destas informações, teríamos que recorrer diretamente as ferramentas do próprio banco de dados para inserir as informações.

Para facilitar, criei também duas telas: ViewAllRules.aspx e AddRule.aspx. A primeira delas exibe uma lista contendo todas as políticas cadastradas, exibindo o caminho (path), ação e tipo, dando também a opção de exclusão. A imagem abaixo exibe essa tela, podendo ser customizada para ter uma melhor aparência:

Basicamente, no evento Load da página invoco o método GetAllRules a partir do provider (classe DBAuthorization) e, com o retorno deste método (DBAuthorizationRuleCollection) carrega o controle DataList. O código para carregar os dados é bem simples:

private void BindRules()
{
this.DataList1.DataSource = DBAuthorization.GetAllRules();
this.DataList1.DataBind();
}

Já a segunda página, AddRule.aspx, disponibiliza um formulário com os devidos campos para a criação de uma nova política. Esse formulário já está configurado com alguns DropDownList’s para assegurar que o usuário que está cadastrando a política escolha apenas um dos tipos ou ações suportadas. Essa página é exibida abaixo:

O único código que temos aqui é a inserção da regra no evento Click do botão “Add Rule”, código qual é mostrado abaixo:

DBAuthorization.AddRule(
    new DBAuthorizationRule()
    {
        Action = Helper.ParseEnum<DBAuthorizationRuleAction>(this.Action.SelectedValue),
        Data = Helper.ExtractCollectionFromString(this.Data.Text.Trim()),
        Path = this.Path.Text.Trim(),
        Type = Helper.ParseEnum<DBAuthorizationRuleType>(this.Type.SelectedValue)
    });

Ao caminho (path) não necessariamente precisa ser uma página ASPX, mas um diretório. Isso pode ajudar quando você precisa proteger um diretório todo. Utilize a página quando precisar de um refinamento da autorização, concedendo acesso específico à um papel ou usuário. Como a busca pelo path está baseado na propriedade Path da classe HttpRequest, a propriedade Path da classe DBAuthorizationRule deve seguir o padrão de URL absoluta, como por exemplo: “/App/Diretorio/Pagina.aspx” ou apenas “/App/Diretorio/”.

Essas telas são simplesmente páginas ASPX que fazem uso do API DBAuthorization para exibir ou criar novas políticas de acesso. Como elas fazem parte de um projeto específico, essas telas não são reutilizáveis por várias aplicações. Fica sob responsabilidade do desenvolvedor criar ou não as telas nas aplicações que deseja fazer uso desta funcionalidade.

DBAuthorization – Parte 8 – Configuração do arquivo Web.config

Israel Aéce — Thu, 05 Mar 2009 18:07:00 GMT

No post anterior acoplamos o módulo DBAuthorizationModule e removemos o módulo UrlAuthorizationModule da execução da aplicação. Isso fará com que a avaliação das políticas seja feita utilizando o provider, que tem o papel de disponibilizar as informações para o módulo e para a aplicação.

Mas as configurações no arquivo Web.config não se resumem a isso. Além das configurações do Membership e Roles, ainda precisamos registrar o provider responsável pela autorização no Web.config. A criação da classe que representa essa seção já foi discutida no artigo em que demonstro como criar um provider customizado. Esse artigo pode ser acessado a partir deste endereço e vou assumir que você tenha o devido conhecimento nisso.

No código abaixo limitei as configurações relevantes do provider, como o registro da seção, a conexão com o banco de dados e a configuração do provider em si. Note que o escolhido foi o “SqlAuthorizationProvider”:

<?xml version="1.0"?>
<configuration>
    <configSections>
        <section
            name="dbAuthorization"
            type="ProjetandoNET.Web.Configuration.DBAuthorizationSection, ProjetandoNET"
            requirePermission="false" />
    </configSections>
    <connectionStrings>
        <clear/>
        <add
            name="SqlConnectionString"
            connectionString="Data Source=.;Initial Catalog=DB;Integrated Security=SSPI;"
            providerName="System.Data.SqlClient" />
    </connectionStrings>
    <dbAuthorization defaultProvider="SqlAuthorizationProvider">
        <providers>
            <add
                name="SqlAuthorizationProvider"
                type="ProjetandoNET.Web.Security.SqlAuthorizationProvider, ProjetandoNET"
                applicationName="WebTeste"
                connectionStringName="SqlConnectionString"
                storeRulesInCache="true"
                commandTimeout="40" />
        </providers>
    </dbAuthorization>
</configuration>

Assim como na configuração do módulo, o registro da seção que criamos e também os tipos dos providers referentes à autorização também devem contemplar o nome completo (namespace + Assembly). Você pode utilizar cada elemento add para adicionar quantos providers forem necessários mas, em runtime, o ASP.NET utilizará o provider especificado no atributo defaultProvider.

DBAuthorization – Parte 7 – DBAuthorizationModule

Israel Aéce — Wed, 04 Mar 2009 08:38:00 GMT

Com o post anterior provemos uma boa performance, garantindo que a mesma informação seja compartilhada entre todos os usuários de uma aplicação específica. Além disso, em posts anteriores analisamos como extrair os dados da fonte de dados mas, tudo o que fizemos até então, é a manipulação de dados, mas a regra para validar se o usuário atual possui ou não direito de acesso não foi definida.

Todas as funcionalidades que falamos no primeiro post desta série estão acopladas ao pipeline do ASP.NET através de módulos (IHttpModule). Se analisarmos o arquivo Web.config do servidor (aquele que está dentro do diretório do .NET Framework), veremos os módulos vinculados à execução da aplicação:

<httpModules>
    <add
        name="WindowsAuthentication"
        type="System.Web.Security.WindowsAuthenticationModule"/>
    <add
        name="FormsAuthentication"
        type="System.Web.Security.FormsAuthenticationModule"/>
    <add
        name="RoleManager"
        type="System.Web.Security.RoleManagerModule"/>
    <add
        name="UrlAuthorization"
        type="System.Web.Security.UrlAuthorizationModule"/>
    <add
        name="FileAuthorization"
        type="System.Web.Security.FileAuthorizationModule"/>
</httpModules>

Os módulos de autenticação são executados de acordo com a opção escolhida no arquivo Web.config (Forms ou Windows). Para autorização, a classe HttpApplication fornece um evento chamado AuthorizeRequest, que é disparado quando chega o momento de determinar a autorização da página requisitada. Os módulos “assinam” esse evento, e são notificados quando ele ocorre e, com isso, executam as verificações necessárias para determinar se o usuário possui ou não os privilégios necessários para acessar a página solicitada.

A UrlAuthorization é a responsável por efetuar essa verificação levando em conta as políticas de acesso que colocamos no arquivo Web.config e, como sabemos, se alteradas forçam o processo do ASP.NET ser reciclado, o que queremos evitar. Como não vamos mais levar em conta as configurações de políticas de acesso que estão no arquivo de configuração, devemos remover este módulo da execução mas, antes disso, ainda é necessário criarmos o nosso.

DBAuthorizationModule é uma classe que implementa a Interface IHttpModule e também assina o evento AuthorizeRequest. No nosso caso, temos que avaliar se o usuário possui ou não privilégio de acesso consultando o provider anteriormente criado. O provider, por sua vez, irá retornar as políticas do cache ou efetuar a busca no banco de dados.

Depois que o provider devolver as políticas definidas, temos que aplicar a regra necessária para conceder ou negar o acesso para o usuário corrente. Mas antes de efetivamente executar essa tarefa, precisamos analisar a propriedade SkipAuthorization da classe HttpContext. Essa propriedade retorna um valor booleano indicando se a autorização deve ou não ser avaliada. Um exemplo disso é quando você solicita a página de Login. Essa página não deve sofrer nenhuma espécie de autorização, já que todos devem acessá-la. Caso essa propriedade retorne False, então devemos avaliar os privilégios do usuário. O código abaixo ilustra o módulo:

public class DBAuthorizationModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.AuthorizeRequest += new EventHandler(OnEnter);
    }

    private void OnEnter(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext context = application.Context;

        if (!context.SkipAuthorization)
        {
            if (!IsUserAllowed(context.User, context.Request.Path, context.Request.RequestType))
            {
                context.Response.StatusCode = 401;
                context.Response.StatusDescription = "Unauthorized";
                application.CompleteRequest();
            }
        }
    }

    public static bool IsUserAllowed(IPrincipal principal, string requestedPath, string verb)
    {
        return DBAuthorization.GetAllRulesByPath(requestedPath).IsUserAllowed(principal, requestedPath, verb);
    }
}

Para avaliar as políticas, criei um método estático chamado IsUserAllowed que recebe como parâmetro o usuário corrente, a página (path) requisitada e o verbo (GET ou POST). Esse método recorre ao provider para recuperar a coleção de regras definidas e, em seguida, invoca o método IsUserAllowed da classe DBAuthorizationRuleCollection informando os mesmos parâmetros. É dentro deste método que toda a “mágica” ocorre, e que por questões de espaço, não será exibida aqui.

Caso os métodos IsUserAllowed retornem False, definimos o código de status de HTTP como 401 (Unauthorized) e invocamos o método CompleteRequest da classe HttpApplication, que obriga o ASP.NET a dar um “bypass” em todos os eventos da classe HttpApplication, direcionando a requisição para o evento EndRequest.

Com o módulo criado, então é necessário adicioná-lo à execução. Mas antes disso, como não faremos uso da Url Authorization, precisamos também removê-la. Dentro do arquivo Web.config da aplicação temos uma seção chamada httpModules. Essa seção permite alistarmos todos os módulos que serão utilizados pela aplicação e, a remoção do módulo “UrlAuthorization” se faz necessária porque em runtime ele mescla os módulos do Web.config do servidor com o da aplicação. Abaixo temos a configuração necessária:

<httpModules>
    <remove
        name="UrlAuthorization"/>
    <add
        name="DBAuthorizationModule"
        type="ProjetandoNET.Web.Security.DBAuthorizationModule, ProjetandoNET"/>
</httpModules>

Note que o tipo (atributo type do elemento add) deve refletir o nome completo da classe, ou seja, incluindo os possíveis namespaces e também o nome do Assembly. As configurações do arquivo Web.config da aplicação não param por aí. Veremos mais detalhes no próximo post desta série.