Como uma estrela em ascensão, o JSP pode ocupar uma determinada posição no ambiente de programação de servidores, o que está intimamente relacionado ao seu bom suporte a uma série de padrões da indústria. A sessão é uma das infraestruturas que ela fornece. Como programador, você pode implementar facilmente o gerenciamento simples de usuários baseado em sessão, sem se preocupar com como ele é implementado no cliente. Existem algumas maneiras diferentes de lidar com usuários online atualmente.
Uma é que a atualização da página é controlada pelo usuário e o servidor controla um tempo limite de 30 minutos. Após o tempo acabar, o usuário será expulso se não houver ação. A vantagem desse método é que se o usuário esquecer de fazer logout, ele pode impedir que outros realizem operações maliciosas. A desvantagem é que se você estiver fazendo algo que leva muito tempo e ultrapassa esse limite de tempo, pode ser necessário fazer login novamente ao enviar. Se a superfície da folha original for forçada a falhar novamente, você poderá perder o trabalho realizado. Do ponto de vista da implementação, este é o mais simples e o lado do servidor implementa esse modo por padrão.
Outra forma é que o site adote uma estrutura de frame, e haja um Frame ou iframe oculto que é constantemente atualizado, para que você nunca seja expulso. Porém, para determinar se você está online, o servidor precisa definir um. tempo de atordoamento. Se você exceder esse tempo de atordoamento, se você não atualizar outras páginas, exceto esta página atualizada automaticamente, será considerado que você não está mais online. Um exemplo típico dessa abordagem é xici.net. Sua vantagem é que ele pode usar atualização contínua para implementar algumas funções semelhantes a push de servidor, como o envio de mensagens entre internautas.
Não importa qual modo seja usado, algum trabalho adicional precisa ser feito para navegar por todos os usuários online no momento. Não há API para obter a lista de sessões na API do Servlet.
O que pode ser usado é o Listener. As especificações do Servlet 2.2 e 2.3 são um pouco diferentes aqui. HttpSessionBindingListener na versão 2.2 pode implementar uma classe que notifica quando o atributo em uma sessão HTTP é alterado.
HttpSessionAttributeListener também foi introduzido em 2.3. Como o ambiente que estou usando é Visual Age para Java 4 e servidor JRun 3.1,eles
não suportam diretamente a programação do Servlet 2.3. Aqui eu uso HttpSessionBindingListener.
implementar a interface HttpSessionBindingListener. Esta interface possui dois métodos:
public void valueBound (evento HttpSessionBindingEvent)
public void valueUnbound (evento HttpSessionBindingEvent)
Quando você executa Session.addAttribute (String, Object), se você adicionou uma classe que implementa a interface HttpSessionBindingListener como um atributo, a sessão notificará sua classe e chame seu método valueBound. Pelo contrário, o método Session.removeAttribute corresponde ao método valueUndound.
A classe pública HttpSessionBinding implementa javax.servlet.http.HttpSessionBindingListener
{
Aplicativo ServletContext = null;
public HttpSessionBinding (aplicativo ServletContext)
{
super();
if(aplicativo==nulo)
throw new IllegalArgumentException("Aplicativo nulo não é aceito.");
este.aplicativo = aplicativo;
}
public void valueBound (javax.servlet.http.HttpSessionBindingEvent e)
{
Vetor activeSessions = (Vetor) application.getAttribute("activeSessions");
if (activeSessions == nulo)
{
sessões ativas = novo Vetor();
}
JDBCUser sessionUser = (JDBCUser)e.getSession().getAttribute("usuário");
if (sessionUser! = nulo)
{
activeSessions.add(e.getSession());
}
application.setAttribute("activeSessions",activeSessions);
}
valor vazio públicoUnbound(javax.servlet.http.HttpSessionBindingEvent e)
{
JDBCUser sessionUser = (JDBCUser)e.getSession().getAttribute("usuário");
if (sessionUser == nulo)
{
Vetor activeSessions = (Vetor) application.getAttribute("activeSessions");
if (activeSessions! = nulo)
{
activeSessions.remove(e.getSession().getId());
application.setAttribute("activeSessions",activeSessions);
}
}
}
} |
Suponha que a classe JDBCUser seja uma classe User arbitrária. Ao realizar o login do usuário, adicione a classe User e a classe HttpSessionBinding à Sessão.
Desta forma, toda vez que um usuário efetuar login, um registro será adicionado ao vetor de atributo “activeSessions” da aplicação. Sempre que a sessão atinge o tempo limite, valueUnbound é acionado e a sessão que está prestes a atingir o tempo limite é excluída desse vetor.
login vazio público()
lança ACLException, SQLException, IOException
{
/* obtém a classe de usuário JDBC */
if (usuário! = nulo)
{
sair();
}
{
// se a sessão expirar ou o usuário não fizer login, salve o URL de destino temporariamente.
JDBCUserFactory uf = new JDBCUserFactory();
if ((this.request.getParameter("userID")==null) || (this.request.getParameter("password")==null) )
{
throw new ACLException("Por favor insira um nome de usuário e senha válidos.");
}
Usuário JDBCUser = (JDBCUser) uf.UserLogin(
this.request.getParameter("userID"),
this.request.getParameter("senha") );
user.touchLoginTime();
this.session.setAttribute("usuário",usuário);
this.session.setAttribute("BindingNotify",new HttpSessionBinding(aplicativo));
}
} |
Ao efetuar login, adicione User e a classe de finalidade BindingNotofy à sessão. Ao efetuar logout, você deve excluir ativamente a sessão no vetor activeSessions. |
|
Essas duas funções estão localizadas em uma classe HttpSessionManager. Esta classe refere-se ao objeto global do aplicativo em jsp. O outro código desta classe não tem nada a ver com este artigo e é bastante longo, então não vou publicá-lo. Vamos dar uma olhada em como usá-lo em JSP. Suponha que um formulário de login seja enviado para doLogin.jsp e que o formulário contenha os campos Nome de usuário e senha. Trechos extraídos: |
|
Vamos ver como obtemos uma lista de usuários online atualmente. |
|
O código acima recupera activeSessions do aplicativo e exibe o horário específico. A classe BeaconDate é considerada uma classe de tempo formatada. Desta forma, obtemos uma estrutura para visualizar a lista de usuários online. Quanto à paginação de listas de usuários online e outras funções, elas são irrelevantes para este artigo e não serão discutidas. Este é um exemplo de modelo sem atualização que depende do mecanismo de tempo limite da sessão. Meu colega sonymusic destacou que muitas vezes isso pode não ser confiável devido às ideias diferentes de cada fabricante. Considerando este requisito, é necessário determinar se o tempo desde a última utilização pelo utilizador actual excede um valor de tempo predeterminado quando cada superfície de folha é actualizada. Isso é essencialmente implementar você mesmo o tempo limite da sessão. Se precisar implementar um modelo de atualização, você deverá usar este método para julgar a atualização para cada superfície de folha. |