Нежелательные разделенные запятыми аргументы для метода контроллера Spring - PullRequest
23 голосов
/ 15 марта 2011

Я вижу странную проблему с контроллером Spring MVC.Этот метод предназначен для установки пароля.Он принимает два параметра формы: «пароль» и «подтверждение пароля».При первом вызове формы это работает нормально - поля передаются методу.

Проблема возникает при повторной отправке формы.Если форма заполнена неправильно в первый раз, пользователь корректно возвращается на страницу формы и получает запрос на повторный ввод пароля.Однако аргументы метода неверны со второй попытки.Аргументы представляют собой список, разделенный запятыми, который включает первую запись формы, соединенную со второй.

Пример:

Первая запись формы с полем "пароль" имеет значение "abc".Аргумент метода «пароль» имеет значение «abc».

Пост второй формы с полем «пароль» и значением «xyz».Аргумент метода «пароль» имеет значение «xyz, abc».

Документы Spring MVC не очень полезны.Каким-то образом старый пост формы запоминается и включается.Кто-нибудь имеет опыт решения этой проблемы?

Метод контроллера ниже:

@RequestMapping(value = "/account/reset", method = RequestMethod.POST)
public String resetPassword(@RequestParam("password") String password,
        @RequestParam("confirmPassword") String confirmPassword,
        @RequestParam("hash") String hash, ModelMap model) throws EncryptionException
{
    String userName = stringEncrypterService.decrypt(hash);
    User user = userService.findUserByPath(userName);

    if (!password.equals(confirmPassword))
    {
        model.put("hash", hash);
        model.put("user", user);
        model.put("error",
                "The two passwords you entered below do not match. Please try again.");

        return "users/resetPassword";
    }

    userService.updatePassword(user, password);
    emailService.sendUserInfoChange(user);
    return "redirect:/session/signin?passwordReset=true";
}

Обновление.Несколько респондентов предположили, что, возможно, проблемные сообщения имеют дополнительные параметры URL или скрытые поля формы, что приводит к дублированию имен полей.Я подтвердил с Fiddler, что это не так.Вот необработанный запрос с третьей попытки.(немного отредактировано для удаления cookie сессии).

POST http://wintest.foriodev.com/simulate/account/reset/ HTTP/1.1
Host: wintest.foriodev.com
Connection: keep-alive
Referer: http://wintest.foriodev.com/simulate/account/reset/
Content-Length: 73
Cache-Control: max-age=0
Origin: http://wintest.foriodev.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.133 Safari/534.16
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: AUTOLOGIN_TOKEN=xyz; SIMULATE_WORKER=wintest; JSESSIONID=xyz; 

password=a&hash=xyz&confirmPassword=a&save=Reset+Password

Ответы [ 8 ]

8 голосов
/ 23 сентября 2011

Я думаю, что причина этого в том, что

return " redirect: / session / signin? PasswordReset = true";

С перенаправлением: платформа используетметод перезаписи URL, аналогичный базовому response.sendRedirect (...) в сервлетах, и, следовательно, значения параметров добавляются вместе с запросом к следующим последовательным запросам и т. д.

Попробуйте использоватьдругой механизм, а не " redirect: "

5 голосов
/ 27 августа 2012

Так что спустя больше года я понял это.

Проблема заключалась в том, что пользовательский перехватчик сохранял кеш запросов при каждом запросе. Я делаю это так, чтобы при входе в систему пользователь возвращался к предыдущему экрану. Но это совершенно неуместно для экрана «Сброс пароля».

Механизм состоял в том, что когда request.getParameter (Name) вызывается, SavedRequestCacheWrapper затем объединяет фактические параметры HTTP-запроса с сохраненными параметрами этого последнего запроса.

Решение состоит в том, чтобы (a) этот перехватчик игнорировал экран сброса пароля и (b) игнорировал все пост-запросы для предотвращения такого рода конкатенации значений параметров запроса.

Другим респондентам, спасибо за все хорошие идеи. (И анонимному пользователю, который назначил награду за это - спасибо, что заставили меня вернуться и еще раз взглянуть.)

4 голосов
/ 22 сентября 2011

Если вы публикуете в третий раз, список тоже увеличится до трех?Это указывает на то, что проблема связана с сеансом пользователя.Или, если список остается на два, то проблема в запросе.Я предполагаю, что список увеличится до трех, так как информация, которую вы разместили в Fiddler, не показывает никаких признаков дублирования в запросе.

Чтобы подтвердить, что данные находятся в сеансе, проверьте их содержимое (например, печатьжурнал, использовать отладчик, распечатать на веб-странице в среде разработчика) для данных под теми же ключами - «пароль», «хэш» и т. д.

Также см. этот другой ответ о том, почему данные могут быть в сеансе пользователя, напр.вы где-то использовали аннотацию @SessionAttributes.

3 голосов
/ 15 марта 2011

Вы получите значения, разделенные запятыми, если у вас есть несколько полей формы с одинаковыми именами. Распространенной причиной этого является скрытый ввод и ввод текста с одинаковым именем. При первой публикации страницы скрытые входные данные будут пустыми, поэтому запятых нет. Во второй (и последующий) раз, когда страница отправляет сообщения, скрытые входные данные будут иметь значения, поэтому вы получите запятые.

2 голосов
/ 15 марта 2011

Похоже, что старые значения так или иначе появляются как параметры GET, то есть либо у вас есть <form action = ".../account/reset?password=abc"> во второй форме, либо action пусто, а URL самой второй формы равен .../account/reset?password=abc.Хотя я не могу найти ничего ответственного за это в вашем коде.

0 голосов
/ 06 июня 2017

В моем случае я связал скрытое поле с неиспользуемым путем.Удаление скрытого поля помогло мне решить проблему.

0 голосов
/ 11 апреля 2012

Похоже, что это может быть вызвано проблемой https://jira.springsource.org/browse/SEC-1258 "SavedRequestAwareWrapper вызывает проблемы в 3.0 M2 в сочетании с Spring MVC"

0 голосов
/ 15 марта 2011

Вы как-то указываете поля формы во второй раз, когда возвращаетесь с шага проверки? Используйте Firebug или что-то подобное, чтобы проверить, что вы отправляете, и / или опубликовать свою страницу jsp (или аналогичную).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...