You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Thomas Mäder (JIRA)" <ji...@apache.org> on 2008/06/17 12:23:45 UTC
[jira] Created: (WICKET-1703) Allow Intercept Page for POST
Requests
Allow Intercept Page for POST Requests
--------------------------------------
Key: WICKET-1703
URL: https://issues.apache.org/jira/browse/WICKET-1703
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.3
Reporter: Thomas Mäder
By throwing RestartResponseAtInterceptPageException an application can temporarily redirect to an intercept page and then continue to the original destination. This is very handy to show a login page if the user is not authorized, for example. Unfortunately, this only works for GET requests. The problem is that only the current request URL is remembered when the exception is thrown and a redirect to this url is issued later. If the intercepted request is a POST, any request parameters are forgotten.
The use case I have in mind is that we have a back end system which has it's own login token which we may lose at any time (for example, if the user logs in again using another tool). Assume that the user is trying to add a new item in a form in the web browser. The problem is that we need to use the back end system to process the submit of that form. It would be nice if we could just show the intercept page and then continue the original form submit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1703) Allow Intercept Page for POST
Requests
Posted by "Jakub Nabrdalik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920491#action_12920491 ]
Jakub Nabrdalik commented on WICKET-1703:
-----------------------------------------
I am not sure how the correct solution should look like (maybe it should be just made clear that you cannot use redirectToInterceptPage with form posts) but there is a workaround.
If you submit the form via AJAX (put AjaxFallbackButton on the form) the problem dissapears, because the client is redirected to the URL from the page (not the target of the ajax request which is a POST to the form/button).
If you'd like your form to work as without ajax (for example because there is too much to refresh), you just need to add
setResponsePage(getPage());
at the end of the ajax submit submit method (i.e.: in ajaxFallbackButton.onSubmit(AjaxRequestTarget target, Form<?> form)), instead of adding stuff to the target.
Only one redirection is send to the client (so it works the same way as redirect after post) and the page the client is returned to is also fine, because it was the requested by GET, not the POST method.
The downside is that you have to make sure your form is not submitted without ajax (for example by pressing enter), as described here: http://richard-wilkinson.co.uk/2008/04/05/how-to-stop-non-ajax-form-submits-in-wicket/
> Allow Intercept Page for POST Requests
> --------------------------------------
>
> Key: WICKET-1703
> URL: https://issues.apache.org/jira/browse/WICKET-1703
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.3
> Reporter: Thomas Mäder
>
> By throwing RestartResponseAtInterceptPageException an application can temporarily redirect to an intercept page and then continue to the original destination. This is very handy to show a login page if the user is not authorized, for example. Unfortunately, this only works for GET requests. The problem is that only the current request URL is remembered when the exception is thrown and a redirect to this url is issued later. If the intercepted request is a POST, any request parameters are forgotten.
> The use case I have in mind is that we have a back end system which has it's own login token which we may lose at any time (for example, if the user logs in again using another tool). Assume that the user is trying to add a new item in a form in the web browser. The problem is that we need to use the back end system to process the submit of that form. It would be nice if we could just show the intercept page and then continue the original form submit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1703) Allow Intercept Page for POST
Requests
Posted by "Thomas Mäder (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605539#action_12605539 ]
Thomas Mäder commented on WICKET-1703:
--------------------------------------
I'd be ready to do the legwork if someone can help me sketch a solution.
> Allow Intercept Page for POST Requests
> --------------------------------------
>
> Key: WICKET-1703
> URL: https://issues.apache.org/jira/browse/WICKET-1703
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.3
> Reporter: Thomas Mäder
>
> By throwing RestartResponseAtInterceptPageException an application can temporarily redirect to an intercept page and then continue to the original destination. This is very handy to show a login page if the user is not authorized, for example. Unfortunately, this only works for GET requests. The problem is that only the current request URL is remembered when the exception is thrown and a redirect to this url is issued later. If the intercepted request is a POST, any request parameters are forgotten.
> The use case I have in mind is that we have a back end system which has it's own login token which we may lose at any time (for example, if the user logs in again using another tool). Assume that the user is trying to add a new item in a form in the web browser. The problem is that we need to use the back end system to process the submit of that form. It would be nice if we could just show the intercept page and then continue the original form submit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.