You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Stijn de Witt <St...@planonsoftware.com> on 2013/12/13 11:13:34 UTC
Wicket session in a Resource
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
RE: Wicket session in a Resource
Posted by Stijn de Witt <St...@planonsoftware.com>.
Thanks Martin, knowing that it is safe to access the session is a real comfort.
Sorry for responding so late, but due to illness I haven't been in the office the end of previous week.
We will look into the patch.
With kind regards,
-Stijn
-----Original Message-----
From: Martin Grigorov [mailto:mgrigorov@apache.org]
Sent: vrijdag 13 december 2013 11:21
To: users@wicket.apache.org
Cc: Coen Wouters
Subject: Re: Wicket session in a Resource
Hi,
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 RequestCycle.
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.deWitt@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-d
> ata-from-servletrequest
> (also see
> http://stackoverflow.com/questions/5466763/how-to-handle-xml-in-body-o
> f-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
>
>
>
>
>
Re: Wicket session in a Resource
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
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
RequestCycle.
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.deWitt@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
>
>
>
>
>