Using IResource instead of a WebPage for JSON response is better.
Using Session.get() in IResource is OK.
Actually IResource is something very similar to normal Servlet.
The benefit is that you have access to the Application, the Session and a

As WICKET-5012 states there is no authentication for resources in 6.x, but
we added it to Wicket 7.x.
Additionally WICKET-5012 has an attachment that you can add to your
application and add authentication for the resources.

On Fri, Dec 13, 2013 at 12:13 PM, Stijn de Witt <
stijn.dew...@planonsoftware.com> wrote:

> Hi Wicket gurus,
> We are trying to implement JSON RPC in Wicket. At first we had made a
> WebPage that would respond with application/json... However, we hit a
> problem here that Wicket parses the parameters of POST requests and puts
> them in the PageParameters map. From there we can get to the parameters,
> but it seems the order of the parameters is lost. Furthermore when we get
> the request inputstream, it is empty already because Wicket ate it up... So
> we have no way of getting the parameters in the order in which they were
> passed...
> So we looked for solutions and found this StackOverflow posting suggesting
> to make a Resource instead:
> http://stackoverflow.com/questions/17874695/wicket-http-post-get-raw-data-from-servletrequest
> (also see
> http://stackoverflow.com/questions/5466763/how-to-handle-xml-in-body-of-a-post-request-with-a-wicket-page)
> In principle this is ok for us... However there is one caveat; it seems
> that it is not possible in Wicket 6.x to have a resource being authorized.
> Also see this Wicket issue:
> https://issues.apache.org/jira/browse/WICKET-5012
> We are using Container Managed Authentication. This means the container
> will intercept all traffic to 'secured' URLs and send them to a login page.
> This is fine for us. However I did notice from debugging that not all code
> is run when the destination is a Resource that would be run if it was a
> Page. There is some authorization logic skipped in Wicket that would have
> run if it was a WebPage... Again this is not really a problem for us, but
> it does bring up one question: Is it ok to use the Wicket session from a
> Resource?
> Let me show some code:
> public class PnWebServiceResource extends AbstractResource
> {
>   // ...
>   @Override protected ResourceResponse newResourceResponse(Attributes
> aAttributes)
>   {
>     HttpServletRequest httpRequest = (HttpServletRequest)
> aAttributes.getRequest().getContainerRequest();
>     // Getting a Reader to the request inputstream works. The reader can
> get the data of the post request.
>     // We could not get this to work when we were extending WebPage
> instead of AbstractResource...
>     Reader reader = new
> InputStreamReader(aHttpServletRequest.getInputStream());
>     WebSession session = WebSession.get();    // <-- Is this safe???
>     // At this point we use the session. It seems to work for now, but is
> this reliable?
>     // Or maybe we are just 'lucky' that we get the right session here?
>   }
> }
> The first lines show how we extend from AbstractResource instead of from
> WebPage. Then, in newResourceResponse, we can get access to the raw POST
> body from the HTTP request as long as we specify a mount path without any
> parameters in it. However, a couple of lines later we access the WebSession
> and we are wondering whether that is save?
> Also, are we maybe following the wrong approach? Is it possible to make a
> WebPage that can access the raw POST body of the request? Or maybe just get
> the PageParameters in a way that guarantees the order is exactly how it was
> in the POST body? The reason the order is important is that we are trying
> to do RPC to a Java method and in Java the order of the method arguments is
> the only info we have at runtime. The names of the arguments are not known.
> So we need to be sure that the parameters are sent to the Java method in
> the same order as they were listed in the request. Afaik, Wicket's
> PageParameters do not guarantee this...
> Any help would be greatly appreciated,
> -Stijn

Reply via email to