За последние два дня, поскольку я использовал Ajax на передней части, чтобы инициировать асинхронный запрос на обновление, я обнаружил, что Ajax выявит адрес интерфейса бэкэнда. Конечно, эта проблема неизбежна, а передняя часть - простой текст. К сожалению, я задал различные вопросы в группах Baidu, Google и QQ. Все они сказали, что проблема может быть решена только посредством проверки безопасности. Как новичок, первый выбор, конечно, сессия. Есть проверка токенов, фрио -фреймворки и т. Д. Онлайн. Друзья, которые заинтересованы, могут искать учебники в Интернете, чтобы учиться.
Сеанс - это механизм кэша для существующих серверов, который может проверить, вошел ли пользователь. Я записал то, что я узнал, чтобы новички могли избежать изгибающих путей и непосредственно загружать код ~
Во -первых, запрос HttpServletRequest request должен быть добавлен в параметры интерфейса входа в систему SSM, чтобы получить сеанс, переносимый запросом.
Во -вторых, установите сеанс в код интерфейса входа в систему, HttpSession session = request.getSession(true); // Это предложение состоит в том, чтобы получить сеанс, истинно означает, что если нет сеанса, создайте новый сеанс, не заполняя его.
session.setAttribute("logined","success"); // Это предложение должно написать логотип. Вы также можете установить учетную запись зарегистрированного в сеансе, чтобы предотвратить злонамеренное подделение информации другой учетной записи при инициировании запроса на модификацию.
В -третьих, как проверить на интерфейсе? Также необходимо использовать параметр запроса httpservlectrequest для получения сеанса, проведенного клиентом, инициирующего HTTP -запрос. HttpSession session = request.getSession(); session.getAttribute("logined") , чтобы прочитать, есть ли зарегистрированный ключ. Если нет входа в систему, запрашиваемый контент не будет предоставлен, и информация будет возвращена непосредственно, чтобы напомнить пользователю войти в систему.
SSM Project Session Проблема
Описание: После того, как пользователь успешно входит в систему, помещает соответствующую информацию пользователя в домен сеанса для легкого вызова и называется XX.
Когда пользователь входит в эту систему, ему/ей нужно изменить свою личную информацию. После того, как модификация завершена, модифицированная личная информация пользователя на странице на стойке регистрации переоценивается в этот домен сеанса, чтобы перезаписать предыдущий сеанс. Таким образом, когда пользователь снова входит в систему или проверяет, информация после того, как он/она меняет ее.
Анализ: Когда пользователь хочет изменить свою личную информацию после изменения своей личной информации (изменение личной информации и изменение личных паролей не находится на одной и той же странице), введенный старым паролем будет предложено быть неверным, потому что нет личного пароля при изменении личной информации. То есть, когда пользователь изменяет свою собственную информацию и вносит свою информацию в сеанс, личный пароль инкапсулируется с пустым значением, и в настоящее время не может быть получен реальный пароль для входа пользователя.
Решение: если вы хотите плавно изменить свой личный пароль после изменения личной информации, вы должны добавить скрытый домен пароля пользователя на страницу, где вы изменяете свою личную информацию. Таким образом, личный пароль для входа будет включен в объект с помощью информации, измененной пользователем, и будет пробит в домен сеанса. Таким образом, внутренний толчок в домене сеанса может быть вызван при изменении пароля, а пароль не будет пустым.
Выше всего содержание этой статьи. Я надеюсь, что это будет полезно для каждого обучения, и я надеюсь, что все будут поддерживать Wulin.com больше.