Antes de definirmos exatamente o que compõem uma aplicação Web no IIS, vamos fazer uma comparação/explanação entre as aplicações Cliente/Servidor tradicionais e as aplicações Web, com ênfase no conceito de conexão e estado.

Uma aplicação Cliente/Servidor tradicional.

Em uma aplicação Cliente/Servidor tradicional, temos o cliente instalada em cada uma das estações da rede que farão acesso a aplicação, podemos ter uma camada de lógica instalada no Servidor de Aplicações, através da qual é feito o acesso ao Banco de dados. Quando o usuário inicia a aplicação cliente, o mesmo se identifica, normalmente através da digitação de um nome de usuário (username ou login) e da digitação de uma senha.

As informações de identificação são utilizadas para estabelecer uma “conexão” com o Servidor. Esta conexão é mantida enquanto a aplicação cliente estiver sendo utilizada. Através desta conexão, o lado Servidor da aplicação consegue identificar o usuário. Com a identificação do usuário podem ser aplicadas regras de segurança, como níveis de permissão de acesso aos dados, níveis de permissão para as funcionalidades da aplicação, log das ações realizadas pelo usuário, etc. Por exemplo, as opções de menu da aplicação Cliente podem ser montados com base nas permissões de acesso que o usuário possui. Se o usuário não possui permissões para alterar os dados, o menu com as opções de alteração não será exibido.

Através da manutenção da conexão e da respectiva possibilidade de identificar unicamente cada um dos usuários conectados, podemos implementar a maioria das funcionalidades fundamentais nas aplicações Cliente/Servidor tradicionais.

Porém existem diversos problemas na atualização e manutenção deste tipo de aplicação, dentre os quais podemos destacar:

• A atualização dos sistemas é problemática, pois neste modelo cada vez que houver alteração na camada de apresentação (no modelo de n camadas) ou até mesmo na camada de Lógica do negócio (no modelo mais antigo de 2 camadas), a aplicação terá que ser atualizada em todas as estações de trabalho que utilizam a aplicação.

Para maiores detalhes sobre os modelos de aplicação de 2 ou mais camadas, consulte os Capítulos 1 e 2.

• Controle de versão: Garantir que todas as estações de trabalho estejam com a última versão da aplicação é uma tarefa nada fácil, a qual, dependendo do número de estações da rede da empresa, pode exigir uma equipe de Help Desk (suporte) praticamente dedicada a esta tarefa.

• Problemas de conflitos de DLL e padronização de ambiente tornam a manutenção e o gerenciamento destas aplicações uma tarefa difícil e de custo elevado.

Estes problemas surgem para cada aplicação Cliente/Servidor tradicional que estiver sendo usada. Agora imagine o caso de uma grande empresa, com milhares de computadores ligados em rede, com dezenas de aplicações. A situação torna-se insustentável, além do custo de manutenção e suporte atingir patamares impraticáveis.

Para resolver estes e outros problemas das aplicações Cliente/Servidor tradicionais é que começaram a ser desenvolvidas aplicações para a Web ou aplicações baseadas em tecnologia Web, como preferem alguns. Vamos falar um pouco mais sobre aplicações Web.

Aplicações Web – um novo paradigma

Para resolver os tradicionais problemas das aplicações Cliente/Servidor é que surge o conceito de aplicação Web.

Para acessar uma aplicação Web o único programa que o usuário precisa é um Navegador instalado na sua estação. Existem inclusive aplicações Web bem projetadas que não obrigam o usuário a utilizar um Navegador específico, o que aumenta mais ainda a flexibilidade.

Uma aplicação Web reside no servidor, no nosso caso no IIS. Toda e qualquer alteração que se fizer necessária na aplicação, será feita diretamente no servidor Web, sem que seja necessária nenhuma modificação nas estações dos usuários. Na próxima vez que o usuário acessar a aplicação, utilizando o Navegador instalado na sua estação, já estarão disponíveis as alterações efetuadas. Com este modelo não é necessária a “atualização” (que muitas vezes significa uma reinstalação) da aplicação em todas as estações da rede, cada vez que forem feitas alterações na aplicação.Com isso, a equipe de suporte fica dispensada da tediosa tarefa de atualização da aplicação em cada estação da rede.

O modelo de aplicações Web traz inúmeras vantagens, dentre as quais podemos destacar:

• Atualização das aplicações centralizada no servidor Web, sem a necessidade de atualizar todas as estações da rede que fazem acesso à aplicação.

• Facilidade de manutenção e suporte, uma vez que o cliente somente precisa de um Navegador para acessar a aplicação.

• Redução do chamado TCO – Total Cost Ownership (Custo Total de Propriedade). O TCO é uma medida de quanto custa, por ano, a manutenção de uma estação de rede em funcionamento. O Cálculo do TCO leva em consideração diversos fatores. Para maiores informações sobre o cálculo do TCO acesse o site do Gardner Group na Internet.

Porém nem tudo são vantagens. Pela natureza e implementação do modelo Web, o qual faz uso do protocolo HTTP, as aplicações Web não tem como manter uma conexão permanente com o usuário. Por isso que o modelo Web, muitas vezes, é conhecido como “State Less”, isto é, “Sem estado”. Isso acontece porque após ter enviado a página solicitada pelo usuário, a conexão é encerrada, não sendo possível continuar trocando informações com o usuário, a não ser que uma nova conexão seja estabelecida. Esta é uma característica intrínseca do protocolo HTTP.

Para vencer as limitações impostas por este modelo “State Less”, o ASP.NET deu passos importantes, com a possibilidade da manutenção do estado dos diversos controles de um formulário Web, entre uma chamada e outra da página, conforme estudamos nos capítulos anteriores.

A possibilidade de diferenciar cada usuário que está acessando uma aplicação Web é de fundamental importância, para que possamos criar conteúdos personalizados e interativos, além da possibilidade de aplicar conceitos como níveis de permissão de acesso aos dados e auditoria de acesso.

O que é uma aplicação Web no IIS?

Agora que já sabemos que o modelo de desenvolvimento baseado na Web é o modelo dominante para o desenvolvimento de novas aplicações, vamos aprender a identificar, quais os elementos que compõem uma aplicação Web no IIS.

De uma maneira simples e didática poderíamos definir uma aplicação Web desenvolvida com ASP ou ASP.NET, como sendo:

“Uma pasta virtual e todas as suas subpastas, juntamente com um conjunto de páginas ASP ou ASP.NET, componentes COM ou COM+ e Web Services, projetados para executar uma ou mais tarefas específicas, como por exemplo um sistema para controlo do departamento de Recursos Humanos.”

O nosso conjunto de páginas ASP pode fazer uso dos diversos componentes disponíveis para a aplicação Web.

No IIS, o primeiro passo para criar uma aplicação Web é criar uma pasta, a qual será o ponto de partida para a aplicação. O próximo passo é transformar esta pasta em uma “Pasta Virtual” do servidor IIS.

Para saber como transformar uma pasta em uma “Pasta Virtual” do IIS, consulte a Introdução e o Capítulo 1 deste livro.

Vamos supor que você tenha criado uma pasta chamada WebApl no drive C:\WebApl, de um servidor IIS chamado www.abc.com.br. Agora você registrou esta pasta como uma pasta virtual chamada WebApl. Dentro deste diretório você criou uma página ASP.NET chamada index.aspx, a qual será a página inicial da aplicação Web. Você lembra como seria o endereço para acessar a página index.asp do diretório virtual WebApl do servidor www.abc.com.br ?

O endereço seria o seguinte: http://www.abc.com.br/WebApl/index.aspx

Dentro da pasta WebApl poderíamos criar outras pastas, conforme a necessidade da nossa aplicação Web. As pastas criadas dentro de uma pasta virtual, já passam a ser acessíveis para o servidor Web. Por exemplo, se dentro da pastas WebApl, criarmos uma pasta chamada Seguranca e dentro da pasta Seguranca colocarmos um arquivo chamado login.aspx. O endereço para acessar o arquivo login.asp seria o seguinte:

http://www.abc.com.br/WebApl/Seguranca/login.aspx

Todos as subpastas da pasta WebApl também farão parte da aplicação Web. Com isso podemos concluir, em um primeiro momento, que uma aplicação Web do IIS está ligada a criação de uma pasta virtual no servidor IIS.

O próximo passo é configurar as propriedades da aplicação Web. Para isso utilizamos o “Gerenciador do Internet Services”, conforme ilustrado nos passos a seguir.

Para configurar as propriedades de uma aplicação Web faça o seguinte:

1.         Faça o logon no Windows 2000 Server, com permissões de administrador.
2.         Abra o Gerenciador do Internet Services: Iniciar -> Programas -> Ferramentas administrativas -> Gerenciador do Internet Services.
3.         Surge a janela indicada na Figura 14.45

Figura 14.45 O Gerenciador do Internet Services.

4.         Esta é a janela do console de administração do IIS 5.0.
5.         Dê um clique duplo no nome do computador. No nosso exemplo o nome é Servidor.
6.         Surgem as opções indicadas na Figura 14.46.

Figura 14.46 Opções de gerenciamento do IIS.

7.         Todos os aplicativos Web estão disponíveis através da opção “Site da Web Padrão”. Dê um clique no sinal de + ao lado desta opção para abri-la.
8.         Serão exibidas todas as pastas virtuais disponíveis no servidor IIS, conforme indicado na Figura 14.47.

Figura 14.47 Pastas virtuas do servidor IIS.

9.         No nosso exemplo queremos configurar as propriedades da pasta virtual WebApl. Neste ponto o conceito de pasta virtual confunde-se com o de aplicação Web. Na verdade a nossa aplicação WebApl está contida na pasta Virtual WebApl.
10.       Dê um clique com o botão direito do mouse sobre WebApl.
11.       No menu de opções que surge dê um clique em Propriedades.
12.       Será exibida a janela “Propriedades de WebApl”, conforme indicado na Figura 8.4.

Figura 14.48 Propriedades da aplicação Web – WebApl.

Observe que nesta janela temos diversas informações, tais como:

Caminho da pasta: C:\WebApl. Este é o caminho físico onde são gravados os elementos da aplicação Web. No nosso exemplo, é a pasta WebApl do drive C:

Permissões de acesso a pasta virtual da aplicação: Observe que por padrão somente são marcadas as opções – Leitura, Criar log e Indexação.

Nome do aplicativo: No nosso exemplo é WebApl.

A principal opção desta janela é o botão Configuração...

13.       Dê um clique no botão Configuração...
14.       Surge a janela Configuração de aplicativo, indicada na Figura 14.49.

Figura 14.49 Configurando as propriedades da aplicação Web – WebApl.

Na primeira guia – Mapeamento de aplicativos, temos a indicação de qual componente do IIS irá processar cada requisição do usuário. Este mapeamento é baseado na extensão do arquivo. Por exemplo, toda página com a extensão .aspx será processada pela DLL aspnet_isapi.dll, conforme indicado pela Figura 14.50.

Figura 14.50 A DLL aspnet_isapi.dll é repsonsável pelo processamento das páginas .aspx.

15.       Não iremos alterar nenhuma opção nesta guia.
16.       Dê um clique na guia Opções de aplicativo.
17.       Na segunda guia – Opções de aplicativo, temos diversas configurações importantes, conforme indicado na Figura 14.51. Estas opções afetam, principalmente, páginas ASP 3.0.

Figura 14.51 Opções da guia – Opções de aplicativo.

Abaixo temos a descrição destas opções:

• Ativar o estado da seção: Esta caixa afeta as páginas ASP 3.0. Use essa caixa de seleção para ativar ou desativar o estado da sessão. Quando o estado da sessão é ativado, o interpretador ASP, cria uma sessão para cada usuário que acessa um aplicativo ASP, de modo que você possa identificar o usuário através das páginas do aplicativo. Quando o estado da sessão é desativado, o ASP não controla usuários e não permite que um script do ASP armazene informações no objeto Session ou use os eventos Session.OnStart ou Session.OnEnd. Uma sessão é finalizada automaticamente se o usuário não solicitou ou atualizou uma página em um aplicativo no fim do tempo limite - TimeOut.

• Tempo limite da seção: No nosso exemplo está definido em 20 minutos. Uma sessão é finalizada automaticamente se o usuário não solicitou ou atualizou uma página em um aplicativo por um tempo maior do que o tempo limite – TimeOut.

• Ativar o Buffer: Esta opção afeta as páginas ASP 3.0. Por padrão esta opção é ativada no IIS 5.0. Nas versões anteriores esta propriedade era desativada por padrão. Quando o Buffer está ativo, o resultado do processamento de uma página ASP somente é enviado para o Navegador do cliente, quando toda a página tiver sido processada, a menos que seja utilizado o método Flush do objeto Response.

• Ativar os caminhos  Pai: Marque esta caixa de seleção para permitir que as páginas ASP usem os caminhos relativos do diretório pai do diretório atual (caminhos que usam a sintaxe ..). , também conhecidos como endereços relativos.

IMPORTANTE! Se você ativar essa opção, não forneça acesso de execução aos diretórios pai, caso contrário, um script poderá tentar executar um programa não autorizado em um diretório pai.

• Linguagem ASP padrão: Por padrão é definida como sendo VBScript. Caso você deseje pode alterar para JScript. Também podemos especificar o nome de qualquer outra linguagem para a qual tenhamos o interpretador instalado no servidor IIS, como por exemplo Perl. Esta opção define a linguagem que será utilizada para interpretar os comandos dentro das tags <% e %>.

• Tempo limite do script ASP: Especifica o período de tempo durante o qual o ASP permitirá a execução de um script. Se a execução do script não terminar ao final do período de tempo limite, o ASP irá parar o script e gravar um evento no log de eventos do Windows 2000. Você pode definir o período de tempo limite como um valor entre 1 e 2147483647, além de poder substituir essa opção em uma página ASP usando o método Server.ScriptTimeout.

18.       Não iremos alterar nenhuma opção nesta guia.
19.       Dê um clique na guia Depuração de aplicativo.
20.       Na terceira guia – Depuração de aplicativo, temos diversas configurações relacionadas com a depuração de erros em páginas ASP, conforme indicado na Figura 14.51.

Figura 14.52 Opções da guia – Depuração de aplicativo.

Abaixo temos a descrição destas opções, que afetam, principalmente, páginas ASP 3.0:

• Ativar a depuração de script ASP do lado do servidor: Marque esta opção para permitir que o servidor Web entre no Depurador de scripts da Microsoft durante o processamento de páginas ASP. Em seguida, você pode usar o depurador para examinar seus scripts. Por questões de desempenho, a depuração do ASP não é recomendada em um ambiente de produção.

• Ativar a depuração de script ASP do lado do cliente: Essa caixa de seleção está reservada para uso futuro e não tem efeito sobre a versão atual do ASP – Esta é a informação contida na própria documentação do IIS 5.0.

• Enviar mensagens de erro do ASP detalhadas para o cliente: Selecione essa opção para enviar informações específicas de depuração (incluindo o nome do arquivo, a mensagem de erro e o número da linha) para o navegador. Principalmente quando estamos desenvolvendo nossas aplicações é importante que esta opção esteja selecionado, pois ao testarmos uma página, se a mesma contiver um erro, o Navegador informa o número da linha onde está o erro, o que facilita a correção do script.

• Enviar mensagem de erro de texto para o cliente: Selecione esta opção para enviar uma mensagem de erro padrão ao navegador quando algum erro impedir o servidor Web de processar a página ASP. Uma mensagem de erro específica é gravada no log de erros. Você pode alterar a mensagem de erro padrão digitando uma nova mensagem na caixa de texto. Não é recomendada a utilização desta opção no ambiente de desenvolvimento, pelos motivos descritos no parágrafo anterior.

21.       Não iremos alterar nenhuma opção nesta guia.
22.       Dê um clique no botão OK para fechar a janela de configuração.
23.       Dê um clique no botão OK para fechar a janela de propriedades da pasta virtual WebApl.
24.       Você estará de volta ao Gerenciador do Internet Services.
25.       Feche-o.

Com isso finalizamos os elementos de segurança ligados ao IIS e ao Windows 2000. Agora vamos estudar alguns aspectos de segurança, específicos das páginas ASP.NET.