Перенаправление с jsf на другую страницу в определенной позиции [дубликат]

Действительно, JSF как платформа, ориентированная на форму, ориентированная на MVC, передает форму POST на тот же URL-адрес, где запрашивается страница с <h:form>. Вы можете подтвердить это, посмотрев URL <form action> сгенерированного вывода HTML. Это в терминах веб-разработки, охарактеризованных как postback . Навигация по обратной передаче по умолчанию не вызывает новый запрос к новому URL-адресу, но вместо этого загружает целевую страницу в качестве содержимого ответа. Это действительно сбивает с толку, когда вы просто хотите навигация по страницам.

Как правило, правильный подход к навигации / перенаправлению зависит от бизнес-требований и idempotence (читайте: «bookmarkability») запроса.

• Если запрос является идемпотентным, просто используйте форму / ссылку GET вместо формы POST (т. е. вместо этого используйте <form>, <h:link> или <h:button> из <h:form> и <h:commandXxx>). Например, навигация по страницам, формам поиска в Google и т. Д.
• Если запрос не является идемпотентным, просто покажите результаты в одном представлении (т. Е. Return null или void и использовать, например, <h:message(s)> и / или rendered). Например, ввод / редактирование данных, многошаговый мастер, модальный диалог, форма подтверждения и т. Д.
• Если запрос не является идемпотентным, но целевая страница является идемпотентной, просто отправьте перенаправление после POST ( т.е. вернуть результат с помощью ?faces-redirect=true или <redirect/>). Например, показывая список всех данных после успешного редактирования, перенаправляя после входа в систему и т. Д.

Обратите внимание, что чистая навигация по страницам обычно является идемпотентной, и именно здесь многие неудачники JSF терпят неудачу злоупотребляя командами / кнопками для этого, а затем жаловаться после этого, что URL-адреса не изменяются. Также обратите внимание, что навигационные случаи очень редко используются в приложениях реального мира, которые разрабатываются в отношении SEO / UX, и это приводит к тому, что многие учебники JSF терпят неудачу, позволяя читателям поверить иначе.

Также обратите внимание, что использование POST абсолютно не «более безопасно», чем GET, поскольку параметры запроса не отображаются сразу в URL-адресе. Они все еще видны в теле запроса HTTP и все еще манипулируются. Поэтому нет абсолютно никаких оснований предпочитать POST для идемпотентных запросов ради «безопасности». Реальная безопасность заключается в использовании HTTPS вместо HTTP и проверке методов бизнес-обслуживания, если в настоящее время зарегистрированный пользователь может запрашивать объект X или манипулировать объектом X и т. Д. Применимая система безопасности предлагает аннотации для этого.

См. также:

• В чем разница между перенаправлением и навигацией / переходом и когда использовать что?
• JSF неявная vs. явная навигация
• Закладка с помощью функции представления параметров
• Что может & lt; f: metadata & gt; , & lt; f: viewParam & gt; и & lt; f: viewAction & gt;
• Когда следует использовать h: outputLink вместо h: commandLink?
• Создание страниц главной страницы для сущностей, как связать их и какую область видимости bean выбрать
• Сохранение параметров строки запроса запроса GET в форме JSF submit
• Передайте объект между объектами @ViewScoped без использования параметров GET