Sessões em ASP.NET

Leituras: 29849 -

Sessões em ASP.NET

     Os aplicativos Web têm um problema intrínseco que os programas Windows nunca tiveram: como manter um valor disponível em todo o aplicativo. Em um programa Windows basta colocar o valor em uma variável global e pronto. Já os programas Web sofrem uma séria deficiência: como o protocolo HTTP não mantém uma conexão entre as chamadas das diferentes páginas, temos que encontrar algum mecanismo para passar informações de uma página para outra. Esta informação pode ser, por exemplo, um carrinho de compras ou um identificador do usuário.

     O mecanismo usado tanto nos programas ASP tradicional como em programas ASP.NET® é basicamente o mesmo: variáveis de sessão. As variáveis de sessão funcionam como dicionários, onde o aplicativo armazena uma chave (uma string ou número inteiro) e um valor (número, strings e vários outros tipos). O interessante é que cada sessão tem uma cópia deste dicionário, esse conjunto dos pares chave-valor. Uma sessão corresponde, a grosso modo, a uma cópia de um navegador acessando o site. Como o servidor não tem como saber se um navegador remoto foi fechado (já que o protocolo HTTP não mantém conexão), as variáveis deixam de existir por "timeout", normalmente no prazo de vinte minutos.

    Para implementar as variáveis de sessão, o ASP e o ASP.NET têm basicamente duas preocupações:

• O navegador remoto deve ser capaz de identificar qual dicionário é "dele". Este identificador é uma "chave" na base de dados das variáveis de sessão;
• A base de dados com todos os dicionários deve ser implementada de alguma forma, em algum servidor.

    No ASP tradicional o identificador de sessão é sempre um "cookie" de sessão e a base de dados fica sempre na memória do servidor. Embora eficientes, este mecanismo pode ter alguns problemas:

• O suporte a cookies pelo navegador pode ser desligado pelo usuário. Alguns usuários confundem os "cookies de sessão" - temporários e inofensivos - com "cookies armazenados", que gravam informações no computador que acessa o site;
• O fato da base de dados residir na memória do servidor Web dificulta a implementação de sites de muito movimento, onde vários servidores Web servem as mesmas páginas. O problema é que se uma sessão é iniciada em um determinado servidor, os outros servidores não podem mais servir aquele usuário, já que apenas um deles enxerga os valores das variáveis de sessão. Existem formas de contornar este problema, mas nenhuma é perfeita.

    O ASP.NET resolve os dois problemas acima. Em primeiro lugar, é possível implementar sessões sem cookies. Em segundo lugar, é possível armazenar a base de dados de sessão de vários servidores Web em um único "servidor de sessão", na rede. Estas opções são especificadas no arquivo de configuração web.config, localizado no mesmo diretório do aplicativo Web.

Entradas no web.config

As entradas que controlam as variáveis de sessão estão sob a tag session. Veja as opções possíveis:

Tag
Significado
Mode
Indica onde são armazenadas as variáveis de sessão.
InProc: Memória do servidor (padrão, igual ao ASP tradicional)
StateServer: Servidor de sessão
SQLServer: Servidor SQL Server
Off: Variáveis de sessão desligadas Cookieless Indica se a sessão usará cookies ou não.
False: Com cookies, igual ao ASP tradicional
True: Sem cookies timeout Tempo em minutos até que sessões sem uso sejam abandonadas. O padrão é vinte minutos. stateConnectionString Nome do servidor e porta usado para a opção mode=StateServer. sqlConnectionString String de conexão SQL para a opção mode=SQLServer.

Veja um exemplo completo:

mode="SQLServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=mas8MAURO;user id=sa;password="
cookieless="true"
timeout="20"
/>

Sessões sem cookies

Para implementar sessões sem cookies, basta abrir o arquivo web.config no Visual Studio .NET ou outro editor de textos, modificar a tag cookieless para true e salvar o arquivo:

. . .
cookieless="true"
/>

Nada mais precisa ser feito. Observe que a URL passa a conter uma string "mágica". Esta string é a mesma usada no cookie quando cookieless=false e também é a chave usada em todos os bancos de dados. Veja um exemplo:



Observe que os links gerados pelos componentes ASP.NET como DataGrid e Hyperlink refletem as mudanças na URL. Se você estiver gerando manualmente uma tag HREF, a sua tag não será alterada; o melhor mesmo é usar o componente Hyperlink.

Mudando o local de armazenamento

Servidor de sessão

O valor padrão de Mode é InProc, onde a base de dados é armazenada na memória do próprio servidor Web. Podemos armazenar a base em um "servidor de sessão" específico mudando a tag Mode para StateServer. Precisamos dizer quem é o servidor de sessão na tag stateConnectionString:

. . .
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
/>

O número "42424" é a porta TCP padrão usada pelo servidor de sessão.

Este servidor de sessão roda um serviço especial chamado "ASP.NET State Service". Este serviço é normalmente instalado junto com o resto do ASP.NET e fica no executável WINDOWSMicrosoft.NETFrameworkversaoaspnet_estate.exe.". Você pode visualizá-lo junto aos outros serviços:



Evidentemente, o servidor de sessão normalmente não fica no mesmo computador que o servidor Web e sim em um computador dedicado. Note também que ele deve ser ligado manualmente, pois seu estado inicial é desligado com início manual.

SQL Server

Para usar o SQL Server 2000 como servidor de sessão, temos que modificar alguns ajustes no web.config e também criar um banco de dados no servidor. Os ajustes no web.config são os seguintes:

mode="SQLServer"
sqlConnectionString="data source=mas8MAURO;user id=sa;password="
/>

sqlConnectionString é a string de conexão ao SQL Server. Ela identifica o nome do servidor, nome e senha usados na conexão. Evidentemente serão diferentes dos valores mostrados acima.

Você deve também criar o banco de dados rodando o script "InstallSqlState.sql", normalmente a partir do diretório "WINDOWSMicrosoft.NETFrameworkv1.0.XXXX".

Rode o "SQL QueryAnalyzer", abra o script e execute-o:



Não é criada nenhuma tabela, e sim várias "stored procedures", estas sim capazes de criar tabelas temporárias. Você pode eliminar o banco de dados rodando o script "UninstallSqlState.sql".

Vantagens de cada modo

Cada modo tem as suas vantagens e desvantagens. InProc oferece a melhor performance de todas, sendo o modo mais recomendável quando apenas um servidor é usado. Já StateServer tem melhor performance que SQLServer e também compatibilidade com "WebFarms". SQLServer também é compatível com "WebFarms", mas com melhor confiabilidade que StateServer, pois o SQL Server pode ser instalado em um "cluster".

Conclusão

Embora do ponto de vista do programador as variáveis de sessão tenham mudado pouco, a sua implementação pode variar bastante e resolver problemas de vários sites com a não-obrigatoriedade do uso de "cookies" e armazenamento dos dados em outros servidores na rede.

 

Escrito por Mauro Sant'Anna

Todos os direitos autorais dos artigos pertencem ao seu autor.