Resources .AXD Encriptados, uma dor de cabeça!
Primeiro post de 2011! Bom deixa eu antes desejar a todos os leitores um grande ano com muitas conquistas e felicidades, esse ano promete ein!
Para o assunto deste post vou abordar um pequeno problema que encontrei em meu dia-a-dia de desenvolvedor, o cenário é o seguinte, ao publicar para produção um sistema desenvolvido e ativar o log de mensagens de erro da aplicação comecei a receber diversos avisos deste tipo:
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /WebResource.axd
Ok, nosso sistema utiliza diversas bibliotecas de controles como Ajax Control Toolkit, controles desenvolvidos por nós mesmos, bibliotecas de validação, entre outras, todos adicionando suas referencias a JavaScript/CSS/Imagens nas páginas passando pelo WebResource.axd urls encriptadas.
Agora como saber quais são estes arquivos que estão sendo solicitados e encontrar o causador ou os causadores de problemas? Após um pequeno periodo pensando como desencriptar tais resources afim de resolver o problema, pesquisando algoritmos para realizar tal operação sem sucesso, foi então que surgiu a idéia “Opa, como o framework faz isto e busca o arquivo para retornar ao usuário?” foi então que após uma outra pesquisada descobri que a própria classe Page (System.Web.UI) possui um método chamado DecryptString usado para desencriptar os resources, “ótimo” deve estar pensando você, basta chamar este método e passar a url e está resolvido.
Infelizmente não foi tão simples assim porque tal método até por segurança do framework possui o modificador private internal e foi ai que surgiu uma idéia perigosa “Reflection!” ótimo, um pouquinho de código e estamos prontos para “burlar” os modificadores de acesso e invocar tal método:
Perfeito, porém perigoso, mais como será um uso pontual e não permanente no sistema está ótimo, até agora conseguimos acesso ao método e supostamente desencriptar qualquer resource recebido, próximo passo é resolver o problema que apenas ocorria em ambiente de produção, esta parte foi simples, bastou adicionar um pequeno trecho no arquivo Global.asax e interceptar todas as requisições a scripts AXD encriptados, em seguida, desencriptar os mesmos e persistir em um arquivo de texto para posterior conferência.
Deixo abaixo o código final para quem possa ser útil:
Por fim teremos um resultado como demonstro ao final deste post e o problema foi resolvido, descoberto qual era o JavaScript que não estava sendo encontrado em um dos componentes desenvolvidos internamente, este foi adicionado e sem mais logs de erro.
Um abraço e novamente um Feliz 2011 a todos, primeiro de muitos!