Métodos assíncronos do ASP.NET Web Services

Ao fazer a referencia para um ASP.NET Web Services (ASMX), automaticamente o proxy é gerado. Antes do WCF, ao referenciar serviços ASMX a versão assíncrona (BeginXXX/EndXXX) dos métodos expostos por ele também eram criados.

Utilizando o Visual Studio .NET 2008, esse comportamento mudou um pouco. Agora temos uma opção chamada “Add Service Reference…” que, dado um endereço (seja ele para um serviço ASP.NET Web Services ou WCF), irá gerar o proxy. A questão é que este proxy baseia-se na infraestrutura do WCF (ClientBase<TChannel>), e a geração dos respectivos métodos assíncronos somente acontecerá se a opção “Generate asynchronous operations” do botão “Advanced” estiver selecionada (maiores detalhes neste artigo). Do contrário, a única forma assíncrona de trabalhar é utilizando o modelo de eventos.

Se quiser continuar gerando o proxy da forma antiga, ou seja, aquele que herda da classe SoapHttpClientProtocol, será necessário recorrer ao utilitário wsdl.exe, como é mostrado abaixo:

C:>wsdl http://localhost:54509/WebService1/Service.asmx /out:C:TempProxy.cs

Anúncios

requirePermission

As seções connectionStrings e appSettings são as únicas que podemos acessar diretamente no código sem nenhum tipo de problema, mesmo quando a aplicação está sendo executada em um ambiente parcialmente confiável. Por parcialmente confiável em uma uma aplicação ASP.NET, entenda como o trust level esteja definido como “Medium” ou algo abaixo disso:

<trust level=”Medium”/>

Neste caso, qualquer outra seção (authentication, smtp, globalization, etc.) que tentarmos acessar em um neste ambiente, uma exceção do tipo SecurityException será lançada informando que não possuímos a permissão necessária que, neste caso, é ConfigurationPermission. Note que só o fato de acessar a seção já provoca o disparo da exceção:

AuthenticationSection section =
    (AuthenticationSection)WebConfigurationManager.GetSection(“system.web/authentication”);
Response.Write(section.Mode.ToString());

Quem determina essa restrição é o atributo requirePermission que é configurado no registro da seção dentro do arquivo de configuração. Por padrão, ele é definido como True e, como dito acima, somente as seções connectionStrings e appSettings são definidas como False, como se pode notar no arquivo machine.config. Somente altere a configuração padrão caso voce realmente saiba o que está fazendo e, principalmente, conhecendo as implicações que isso pode causar. Além disso, é importante dizer que voce também pode determinar essa restrição quando voce cria uma seção de configuração customizada.

Acesso anônimo à arquivos *.svc

Ao efetuar o deploy de uma aplicação que utiliza a configuração padrão de um projeto do tipo WCF Service (arquivos *.svc), obrigatoriamente voce precisa permitir o acesso anônimo ao diretório virtual. Caso essa configuração não seja realizada, ao tentar acessar o serviço uma exceção do tipo NotSupportedException será disparada:

Security settings for this service require ‘Anonymous’ Authentication but it is not enabled for the IIS application that hosts this service.

Habilitar a autenticação anônima resolve o problema, mas em alguns cenários isso não é aceitável. A forma de resolver isso é alinhar as configurações de autenticação do serviço (arquivo Web.config) com as configurações do diretório virtual. O primeiro passo é desabilitar o acesso anônimo no diretório virtual, permitindo apenas a autenticação Windows. Neste caso,  a configuração do binding deve ser definida como autenticação Windows, refletindo a mesma configuração do IIS; já quando o modo de seguraça estiver definida como TransportCredentialOnly que “desliga” o acesso anônimo ao serviço. Com a configuração abaixo já é possível acessar o serviço sem o acesso anônimo habilitado no IIS:

<bindings>
  <basicHttpBinding>
    <binding name=”bndConfig”>
      <security mode=”TransportCredentialOnly”>
        <transport clientCredentialType=”Windows”/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

Um outro detalhe importante, é que endpoints para publicação do documento WSDL também exigem a autenticação anônima, e se tiver este endpoint no serviço, a mesma exceção que vimos acima será disparada. Para contornar este problema, voce deverá utilizar as mesmas regras de configurações de autenticação para este endpoint mas, os bindings exclusivos para publicação de metadados (mex*) não possuem características de segurança que possam ser configuradas. Podemos configurar o endpoint que expõe os metadados a partir de bindings convencionais e, com isso, ter acesso à todas as configurações de segurança que o WCF fornece. Abaixo consta a configuração geral deste cenário:

<endpoint
    address=””
    binding=”basicHttpBinding”
    contract=”IService”
    bindingConfiguration=”bndConfig” />
<endpoint
    address=”mex”
    binding=”basicHttpBinding”
    contract=”IMetadataExchange”
    bindingConfiguration=”bndConfig” />

<bindings>
  <basicHttpBinding>
    <binding name=”bndConfig”>
      <security mode=”TransportCredentialOnly”>
        <transport clientCredentialType=”Windows”/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

.NET 3.5 SP1 GDR (Fixes)

Está disponível a partir deste link uma atualização para o .NET Framework 3.5 SP1. Esta atualização também faz algumas poucas mudanças no WCF e, entre elas, o envio correto do código de status do protocolo HTTP quando a autenticação via HTTP é inválida.

Como já foi mencionado neste kb, quando utilizamos um autenticador customizado no WCF, disparamos a exceção SecurityTokenValidationException para informar ao runtime que o usuário é inválido. Quando o runtime identifica essa exceção, ele traduz a mesma para o código 403 (Forbidden) do HTTP. A mudança que é realizada com esta atualização é que ao invés de retornar 403, passará a retornar o código 401 (Unauthorized), que acaba sendo mais coerente com a situação.