Re: Wicket CSRF/XSRF protection
Il 30/12/2015 15:25, Martin Grigorov ha scritto: Hi, You can use CookieUtils to write the cookie. Later in each request you could use WebRequest.getHeader(String) or @HeaderParam if this is supported. Hi and happy new year, Thank for the answer. So, in my case, the best way is to manage the cookie "manually"? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Dec 30, 2015 at 9:31 AM, andrea wrote: Hi all, Starting from [this][1] question on stackoverflow, I'm going to ask one thing more. I've developed a web application in which Apache Wicket plays as "REST backend", it only exposes HTTP Resources, there is an application and there are no pages, and no html related. All "frontend" is developed in AngularJS. Now, I need protection against CSRF attacks. AngularJS documentation says: To take advantage of this [angular XSRF protection], your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on first HTTP GET request. On subsequent non-GET requests the server can verify that the cookie matches X-XSRF-TOKEN HTTP header, and therefore be sure that only JavaScript running on your domain could have read the token. How can I get this token managed by Apache Wicket? Are there wicket implementations of such mechanism? I found /*CsrfPreventionRequestCycleListener*/ but this doesn't protect all requests, it seems to be configured (by default) only to protect ajax requests on components or links; or /*CryptoMapper*/ with /*KeyInSessionSunJceCryptFactory*/, but this does not seem to do what I'm looking for. I "just" want to send a token, not to crypt urls, but if guarantees the same protection I'll do. I've not found so much on documentation, can you help me? [1]: http://stackoverflow.com/questions/29881338/add-csrf-protection-header-to-wicket-ajax-call#new-answer Best regards, Andrea - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
On Fri, Jan 1, 2016 at 10:26 PM, Martin Grigorov wrote:
> Hi,
>
> On Tue, Dec 29, 2015 at 2:14 PM, Daniel Stoch
> wrote:
>
>> Another problem with WebSocketRequest:
>>
>> @Override
>> public Url getUrl()
>> {
>> return null;
>> }
>>
>> @Override
>> public Url getClientUrl()
>> {
>> return null;
>> }
>>
>> null result in getUrl() method can leed to execptions in
>> UrlRequestParametersAdapter:
>>
>> java.lang.IllegalArgumentException: Argument 'url' may not be null.
>> at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
>> at
>> org.apache.wicket.request.parameter.UrlRequestParametersAdapter.(UrlRequestParametersAdapter.java:48)
>> at
>> org.apache.wicket.request.Request.getQueryParameters(Request.java:128)
>> at
>> org.apache.wicket.request.Request.getRequestParameters(Request.java:136)
>>
>> Maybe these methods should better return empty Url instead of null (
>> return new Url(); )?
>>
>
> Please file a separate ticket with a quickstart app!
> Thank you!
WICKET-6063
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
On Fri, Jan 1, 2016 at 10:25 PM, Martin Grigorov wrote: > Hi, > > > On Mon, Dec 28, 2015 at 4:49 PM, Daniel Stoch > wrote: > >> Hi, >> >> As I wrote in my previous post "Native WebSockets - cookies and last >> handler question": In WebSocketResponse many methods throws >> UnsupportedOperationException. Some of them can be customized now >> thanks to WICKET-6054. >> >> But I have found another problem with WebSocketResponse.sendRedirect() >> method. When you send a message using >> IWebSocketConnection.sendMessage() and an exeption is raised somewhere >> during processing of this message you can get the following exception >> (the orignal exception is lost): >> >> Error during processing error message >> java.lang.UnsupportedOperationException >> at >> org.apache.wicket.protocol.ws.api.WebSocketResponse.sendRedirect(WebSocketResponse.java:205) >> at >> org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:176) >> at >> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:327) >> at >> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175) >> at >> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:890) >> at >> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) >> at >> org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:251) >> at >> org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:43) >> >> >> This is because WebPageRenderer by default calls redirectTo method. So >> it looks like WebSocketResponse.sendRedirect() should not throw >> exception in the default implementation? >> > > The default is to throw an exception so that you know that you are trying > to do something that is really not supported. > But now I think we can actually add support for it - as Ajax does with > ... > Please file a ticket with a quickstart app! > Thank you! > WICKET-6064 BTW: The quickstart app is not compatible with websockets when you are trying to use Start.main(): java.lang.IllegalStateException: Websockets not supported on blocking connectors at org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory.java:237) at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:396) at org.apache.wicket.protocol.ws.jetty.Jetty7WebSocketFilter.acceptWebSocket(Jetty7WebSocketFilter.java:74) at org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:55) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:556) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372) at org.eclipse.jetty.server.session.SessionHandler.doScope(Sessio
