Nos últimos dois dias, porque usei o Ajax no front -end para iniciar uma solicitação de atualização assíncrona, descobri que o Ajax exporia o endereço da interface do back -end. Obviamente, esse problema é inevitável e o front end é o texto simples. Infelizmente, fiz várias perguntas nos grupos Baidu, Google e QQ. Todos eles disseram que o problema só pode ser resolvido através da verificação de segurança. Como novato, a primeira opção é obviamente sessão. Existem verificação de token, estruturas Shrio, etc. online. Amigos interessados podem procurar tutoriais on -line para aprender.
A sessão é um mecanismo de cache para os servidores existentes, que podem verificar se o usuário efetuou login. escrevi o que aprendi para que os novatos possam evitar caminhos de dobrar e fazer o upload diretamente do código ~
Primeiro, a solicitação HttpServletRequest request deve ser adicionada aos parâmetros da interface de login do SSM para obter a sessão realizada pela solicitação.
Segundo, defina a sessão no código da interface de login, HttpSession session = request.getSession(true); // Esta frase é para obter sessão, verdadeiro significa que, se não houver sessão, crie uma nova sessão sem preencher ela.
session.setAttribute("logined","success"); // Esta frase é escrever um logotipo. Você também pode definir a conta logada na sessão para evitar adulteres maliciosamente com as informações de outra conta ao iniciar uma solicitação de modificação.
Terceiro, como verificar na interface? Também é necessário usar o parâmetro de solicitação httpServletRequest para obter a sessão transportada pelo cliente iniciando uma solicitação HTTP. HttpSession session = request.getSession(); session.getAttribute("logined") para ler se existe uma tecla loginada. Se não houver login, o conteúdo solicitado não será fornecido e as informações serão devolvidas diretamente para lembrar o usuário para fazer login.
Problema do escopo da sessão do projeto SSM
Descrição: Depois que o usuário faz login no sistema com sucesso, coloca as informações relevantes do usuário em um domínio de sessão para facilitar a chamada e é nomeado xx.
Quando o usuário faz login nesse sistema, ele precisa modificar suas informações pessoais. Após a conclusão da modificação, as informações pessoais modificadas do usuário na página da recepção são reabastecidas neste domínio da sessão para substituir a sessão anterior. Dessa forma, quando o usuário faz login novamente ou verifica, as informações depois que ele alteram.
Análise: Quando o usuário deseja modificar suas informações pessoais após modificar suas informações pessoais (modificando informações pessoais e modificando as senhas pessoais não estão na mesma página), a senha antiga inserida será solicitada a estar errada, porque não há senha pessoal ao modificar informações pessoais. Ou seja, quando o usuário modifica suas próprias informações e enfia suas informações na sessão, a senha pessoal é encapsulada com um valor vazio, e a senha real para o login do usuário não pode ser obtida no momento.
Solução: se você deseja modificar sem problemas sua senha pessoal após modificar suas informações pessoais, adicione um domínio oculto da senha do usuário à página em que modifica suas informações pessoais. Dessa forma, a senha de login pessoal será encapsulada no objeto com as informações modificadas pelo usuário e será recheado no domínio da sessão. Dessa forma, o empurrão interno no domínio da sessão pode ser chamado ao modificar a senha e a senha não estará vazia.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.