Eu costumava confiar muito em variáveis de sessão no passado, mas recentemente descobri que muitas delas são desnecessárias, usando coisas como parâmetros de string de consulta.
Um colega meu se recusa a usar variáveis de sessão. Esse é um objetivo realista e as variáveis da sessão devem ser evitadas por qualquer motivo prático? As variáveis de sessão podem ser completamente evitadas (exceto os cookies de sessão para permitir logins) e isso resultaria em melhores designs?
Alguns dos motivos pelos quais meu colega não os usou:
- Natureza não digitada das variáveis da sessão
- Tempos limite da sessão causando perda de estado
- Natureza do escopo global das variáveis de sessão
- Servidores de balanceamento de carga que perdem sessões (específico .Net?)
- Pools / servidores de aplicativos reiniciando
- Eles são desnecessários
web-development
design
Tjaart
fonte
fonte
using things like query string parameters instead- Neste caso, sempre use sempre os parâmetros da string de consulta, se possível. O uso da sessão para esse tipo de parâmetro é frágil e pode apresentar erros estranhos quando os usuários têm várias guias abertas.Respostas:
Se você tem uma variável de sessão em seu aplicativo, pergunte a si mesmo:
Se a resposta for "o valor atual", as variáveis da sessão podem ser úteis. Um exemplo seria um carrinho de compras: você não espera que as coisas sejam removidas do carrinho de compras ao voltar ao histórico. Está sempre em seu estado atual.
Se a resposta for "um valor anterior", você não deve usar variáveis de sessão. Os maus usos que vi incluem a passagem de um parâmetro entre as páginas. Se eu clicar no botão Voltar para retornar a uma página, a página não obterá necessariamente o parâmetro correto. Além disso, se eu abrir duas guias, como o meu site se comportará?
Consertar corretamente o comportamento do botão Voltar não é de jeito nenhum, mas ajuda você a pensar em um site como um aplicativo sem estado. Em geral, acho que os usos apropriados das variáveis de sessão são poucos e distantes entre si.
fonte
O protocolo HTTP é sem estado. As sessões são uma maneira de preservar o estado do cliente nas solicitações HTTP. Você pode optar por fazer isso com o tratamento de sessão interno de uma plataforma ou fazer você mesmo com os parâmetros da cadeia de caracteres de consulta. De qualquer maneira, é necessário algum conceito de sessão para muitas tarefas.
Seu colega provavelmente não gosta de uma implementação específica ou não está usando sessões para os fins pretendidos. Se você precisar reter informações sobre uma conexão específica do cliente através de solicitações HTTP, precisará de alguma forma de persistência da sessão.
Os seguintes problemas são específicos da implementação:
Por exemplo, na maioria das vezes eu trabalho em PHP e armazeno minhas informações de sessão em um banco de dados relacional. Então, minhas variáveis de sessão são digitadas. O balanceamento de carga e as reinicializações do servidor não causam problemas na sessão.
Este é mais interessante:
As sessões são mais frequentemente preservadas por meio de cookies. Estes podem ser excluídos pelo cliente a qualquer momento. Mas eles também podem ser preservados por meio de um parâmetro de sequência de consultas e, portanto, nunca atingem o tempo limite no cliente. O tempo limite do servidor depende de você. Portanto, mesmo esse problema é específico da implementação.
Não vamos jogar fora todo o conceito de sessões apenas porque não gostamos de uma implementação específica. Qualquer boa estrutura de aplicativo da Web facilitará o uso de sessões adequadamente para preservar logins do usuário ou reter qualquer outra coisa específica da visita atual do usuário. O registro do banco de dados de um usuário pode (e deve) ser usado para armazenar itens específicos a ele quando conectado. Os visitantes anônimos, no entanto, também podem ter informações temporárias que devem ser preservadas em sua sessão, como uma pequena lista de páginas recentes visitadas ou a preferência por esconda um aviso que eles já viram. Geralmente, apenas informações temporárias menores são apropriadas para o armazenamento da sessão.
fonte
Outros fizeram muitos pontos positivos (que evitarei repetir), mas há um aspecto da técnica de seu amigo que ainda não foi discutido: segurança .
É impossível saber que tipo de vulnerabilidades você abre sem olhar para o código, mas aqui estão algumas coisas que eu posso pensar em cima da minha cabeça.
Tudo isso ainda pode acontecer quando você usa Sessões, mas pode ficar muito mais fácil se o seu amigo não souber o que está fazendo.
fonte
As variáveis de sessão são como as antigas variáveis globais básicas até certo ponto. O ônus é do usuário acompanhar, o que está neles, seu escopo e como são usados; assim como nas versões antigas do BASIC. Dito isto, por que alguém descartaria totalmente o uso de um mecanismo que obviamente é projetado para ser parte integrante e muito importante do modelo de programação (ASP, MVC etc.)?
A única coisa ruim em que me deparei com o uso de variáveis de Sessão é que isso sobrecarrega você para acompanhá-las, garantir que elas sejam preenchidas com dados relevantes e descartá-las.
Não é isso que fazemos quando estamos programando alguma maneira?
fonte
Eu costumava pensar como seu colega devido a algumas experiências ruins que eu tive problemas de depuração relacionados a variáveis de sessão, que eram realmente apenas incompetência da minha parte. Sim, você pode sobreviver, até certo ponto, sem variáveis de sessão, usando cadeias de consulta, campos ocultos em formulários e outras coisas. No entanto, fica muito difícil fazê-lo dessa maneira, se seu aplicativo tiver algo além do fluxo lógico mais básico para determinar o estado. Há também o risco de segurança de mostrar o funcionamento interno do seu aplicativo por meio de cadeias de consulta e campos ocultos, qualquer um dos quais pode servir como vetores de ataque.
Ao trabalhar com variáveis de sessão, você só precisa acompanhar quando elas são definidas e desabilitadas, pois isso determinará o fluxo lógico do aplicativo. É como o gerenciamento de memória em um idioma como C.
Observe que isso é apenas da minha experiência trabalhando com PHP em um projeto relativamente pequeno, sem estruturas, as coisas podem ser diferentes em outras plataformas, mas acho que o princípio geral ainda se aplica.
fonte
Como indicado anteriormente, o HTTP é Stateless e a Session Variable quebra isso. O design do HTTP para ser sem estado ajuda a armazenar em cache os recursos. Para recursos disponíveis publicamente.
É possível criar um site sem variável de sessão, mas é mais difícil. O mais difícil (IMHO) é o sofisticado login / logout, os esquemas de autenticação HTTP não fornecem as ferramentas necessárias para autenticação através de um formulário HTML (você pode hackear algo com javascript - XHR para https: // untel: [email protected] ) e é ainda mais difícil sair e ser compatível com vários navegadores. houve alguma discussão nas listas de discussão do w3 sobre isso, mas se bem me lembro, a ideia foi descartada.
Quanto ao resto, você deve poder viver sem variáveis de sessão. Você terá algum estado em um banco de dados, arquivos ou em qualquer lugar, mas o uso para variáveis de sessão deve ser raro.
Se o seu usuário tiver um carrinho de compras, será uma sessão variável apenas se o usuário puder navegar em dois computadores / navegadores sem compartilhar o carrinho.
fonte