date:20170515

Re: Balancer + HTTPS

2017-05-15 Thread Marcel Barbosa Pinto

Hi Martin,

The #sendRedirect sends a relative URL and them the servlet generates the
Location header with the original location with HTTP instead the
X-Forwarded-Proto scheme.
The balancer also sends a X-Host header, so I had to concatenate the host
and scheme to the URL before the #sendRedirect call.

Thanks.

On Mon, May 15, 2017 at 11:21 AM, Marcel Barbosa Pinto <
marcel.po...@gmail.com> wrote:

> Hi Martin,
>
> I've found something that could be related, at this line below, a new Url
> instance is created without being configured with the protocol. Is this URL
> relative or absolute?
>
> https://github.com/apache/wicket/blob/9e42a9548adb0da540e4e87d491f58
> 24e778537e/wicket-core/src/main/java/org/apache/wicket/
> core/request/mapper/PageInstanceMapper.java#L129
>
> I'll will try to debug the code later.
> Thanks.
>
>
>
>
> On Mon, May 15, 2017 at 3:56 AM, Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> Put a breakpoint at org.apache.wicket.request.Url#getProtocol() and see
>> what it returns.
>> I guess the redirect is an absolute url and that's why it breaks.
>> See org.apache.wicket.protocol.http.servlet.ServletWebResponse#s
>> endRedirect
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, May 15, 2017 at 5:01 AM, Marcel Barbosa Pinto <
>> marcel.po...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > I am using a balancer which sends the X-Forwarded-Proto header to my
>> Wicket
>> > application.
>> >
>> > I`ve added the following filters:
>> >
>> >  getFilterFactoryManager()
>> > > .addSecuredRemoteAddressRequestWrapperFactory(null)
>> > > .addXForwardedRequestWrapperFactory(null);
>> > >
>> >
>> > And the HttpsMapper:
>> >
>> > setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
>> > > HttpsConfig())
>> > >
>> >
>> >
>> > And the following init-param into web.xml
>> >
>> > 
>> > >   protocolHeader
>> > >   X-Forwarded-Proto
>> > >  
>> > >
>> >
>> >
>> > When I debug I can see that the header is working inside a
>> > RequestCycleListener
>> >
>> > HttpServletRequest req = (HttpServletRequest)
>> > > cycle.getRequest().getContainerRequest();
>> > > System.out.println("-->" + req.getScheme() + " ==" +
>> > > req.getHeader("X-Forwarded-Proto");
>> > >
>> >
>> >
>> > The problem occurs when some versioned page is created and wicket
>> redirect
>> > it to the same URL but with the HTTP:// instead, for example:
>> >
>> > *https://*www.wicket.com/statefullPage
>> > -> Response header: 302 (Location: *http://*www.wicket.com/
>> > statefullPage*?1*
>> > )
>> >
>> > If I change it back to HTTPS it works:
>> >
>> > *https://*www.wicket.com/statefullPage
>> > *?1*
>> > *-> *Response 200 OK
>> >
>> > I believe that in some redirection logic the original schema is being
>> lost
>> > somehow, during page versioning.
>> > This problem only occurs when using the "X-Forwarded-Proto" header
>> >
>> > Using Wicket 7.6.0
>> > Any suggestions?
>> >
>> > Thanks!
>> >
>>
>
>
>
> --
>
> Marcel Barbosa Pinto
> 55 11 98255 8288
>



-- 

Marcel Barbosa Pinto
55 11 98255 8288

Re: WebSockets and CsrfPreventionRequestCycleListener

2017-05-15 Thread Maxim Solodovnik

I just have checked CsrfPreventionRequestCycleListener with overriden
isChecked and it produces no errors

I would vote for WebSocketAwareCsrfPreventionRequestCycleListener :)

On Tue, May 16, 2017 at 5:50 AM, Martin Grigorov  wrote:
> Hi Maxim,
>
> You can use
>
> getRequestCycleListeners().add(new CsrfPreventionRequestCycleListener() {
> @Override
> protected boolean isChecked(IRequestHandler handler)
> {
> if (handler instanceof WebSocketRequestHandler || handler instanceof
> WebSocketMessageBroadcastHandler) {
> return false;
> }
> return super.isChecked(handler);
> }
> });
>
>
> The upgrade request has a proper Origin header:
>
>
>1. Accept-Encoding:
>gzip, deflate, sdch, br
>2. Accept-Language:
>en-US,en;q=0.8,bg;q=0.6
>3. Cache-Control:
>no-cache
>4. Connection:
>Upgrade
>5. Cookie:
>
>6. DNT:
>1
>7. Host:
>localhost:8080
>8. Origin:
>http://localhost:8080
>9. Pragma:
>no-cache
>10. Sec-WebSocket-Extensions:
>permessage-deflate; client_max_window_bits
>11. Sec-WebSocket-Key:
>FcSNIsIh3HO95UGmMUA27g==
>12. Sec-WebSocket-Version:
>13
>13. Upgrade:
>websocket
>14. User-Agent:
>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
>Chrome/57.0.2987.110 Safari/537.36
>15.
>
> But the following communication is via the WebSocket connection and the
> packets there do not bring request headers.
> Wicket Native WebSocket module creates WebSocketRequest for each WS message
> and those do no have request headers, so they can be safely ignored.
> Maybe we can introduce WebSocketAwareCsrfPreventionRequestCycleListener in
> wicket-native-websocket-core and recommend its usage when the app uses
> WebSockets ?!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, May 15, 2017 at 11:26 AM, Maxim Solodovnik 
> wrote:
>
>> Example project demonstrating it is here:
>> https://github.com/solomax/ajax-download
>>
>>
>> html with WebSocket.send:
>> https://github.com/solomax/ajax-download/commit/
>> 84af661b1e5e110419f17dbf9295547c135a0cc5#diff-
>> 217ea4d3217197ce4ece382e050a7302R26
>>
>> On Mon, May 15, 2017 at 3:14 PM, Maxim Solodovnik 
>> wrote:
>> > Thanks a lot for checking Martin,
>> >
>> > The issue seems to be caused by following code in *.html (reproducible
>> > using quickstart)
>> >
>> > 
>> > $(function() {
>> >   Wicket.Event.subscribe(Wicket.Event.Topic.WebSocket.Opened,
>> function() {
>> > Wicket.WebSocket.send("socketConnected");
>> >   });
>> > });
>> > 
>> >
>> > I guess I need to manually set missing headers in such call
>> >
>> > Can you please help to set necessary headers?
>> >
>> > On Mon, May 15, 2017 at 1:50 PM, Martin Grigorov 
>> wrote:
>> >> Hi Maxim,
>> >>
>> >> Just adding getRequestCycleListeners().add(new
>> >> CsrfPreventionRequestCycleListener());
>> >> to org.apache.wicket.examples.websocket.JSR356Application#init()
>> doesn't
>> >> lead to any error.
>> >>
>> >> Martin Grigorov
>> >> Wicket Training and Consulting
>> >> https://twitter.com/mtgrigorov
>> >>
>> >> On Mon, May 15, 2017 at 7:54 AM, Maxim Solodovnik > >
>> >> wrote:
>> >>
>> >>> Hello Martin,
>> >>>
>> >>> were you able to take a look at it?
>> >>> I was hoping to have M6 with working Csrf+WebSockets 
>> >>>
>> >>> On Fri, May 12, 2017 at 4:45 PM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> >>> wrote:
>> >>> > Thanks a million, Martin :)
>> >>> >
>> >>> > On Fri, May 12, 2017 at 4:34 PM, Martin Grigorov <
>> mgrigo...@apache.org>
>> >>> wrote:
>> >>> >> Hi Maxim,
>> >>> >>
>> >>> >> I don't use this combination.
>> >>> >> But I will try to test it soon and see what can be done.
>> >>> >>
>> >>> >> Martin Grigorov
>> >>> >> Wicket Training and Consulting
>> >>> >> https://twitter.com/mtgrigorov
>> >>> >>
>> >>> >> On Fri, May 12, 2017 at 11:00 AM, Maxim Solodovnik <
>> >>> solomax...@gmail.com>
>> >>> >> wrote:
>> >>> >>
>> >>> >>> Does anybody uses this filter?
>> >>> >>>
>> >>> >>> On Thu, May 11, 2017 at 10:44 AM, Maxim Solodovnik <
>> >>> solomax...@gmail.com>
>> >>> >>> wrote:
>> >>> >>> > Hello All,
>> >>> >>> >
>> >>> >>> > just have tried to add CsrfPreventionRequestCycleListener to our
>> >>> >>> application
>> >>> >>> > everything seems to work except for Websockets :(
>> >>> >>> >
>> >>> >>> > Now I'm getting
>> >>> >>> >
>> >>> >>> > [INFO] [http-nio-0.0.0.0-5080-exec-9]
>> >>> >>> > org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener
>> -
>> >>> >>> > Possible CSRF attack, request URL:
>> >>> >>> > /openmeetings/wicket/websocket?pageId=1
>> >>> >>> ajax-baseurl==OpenmeetingsApplication,
>> >>> >>> > Origin: null, action: aborted with error 400 Origin does not
>> >>> >>> > correspond to request
>> >>> >>> > [WARN] [http-nio-0.0.0.0-5080-exec-9]
>> >>> >>> >

Re: WebSockets and CsrfPreventionRequestCycleListener

2017-05-15 Thread Martin Grigorov

Hi Maxim,

You can use

getRequestCycleListeners().add(new CsrfPreventionRequestCycleListener() {
@Override
protected boolean isChecked(IRequestHandler handler)
{
if (handler instanceof WebSocketRequestHandler || handler instanceof
WebSocketMessageBroadcastHandler) {
return false;
}
return super.isChecked(handler);
}
});


The upgrade request has a proper Origin header:


   1. Accept-Encoding:
   gzip, deflate, sdch, br
   2. Accept-Language:
   en-US,en;q=0.8,bg;q=0.6
   3. Cache-Control:
   no-cache
   4. Connection:
   Upgrade
   5. Cookie:
   
   6. DNT:
   1
   7. Host:
   localhost:8080
   8. Origin:
   http://localhost:8080
   9. Pragma:
   no-cache
   10. Sec-WebSocket-Extensions:
   permessage-deflate; client_max_window_bits
   11. Sec-WebSocket-Key:
   FcSNIsIh3HO95UGmMUA27g==
   12. Sec-WebSocket-Version:
   13
   13. Upgrade:
   websocket
   14. User-Agent:
   Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
   Chrome/57.0.2987.110 Safari/537.36
   15.

But the following communication is via the WebSocket connection and the
packets there do not bring request headers.
Wicket Native WebSocket module creates WebSocketRequest for each WS message
and those do no have request headers, so they can be safely ignored.
Maybe we can introduce WebSocketAwareCsrfPreventionRequestCycleListener in
wicket-native-websocket-core and recommend its usage when the app uses
WebSockets ?!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, May 15, 2017 at 11:26 AM, Maxim Solodovnik 
wrote:

> Example project demonstrating it is here:
> https://github.com/solomax/ajax-download
>
>
> html with WebSocket.send:
> https://github.com/solomax/ajax-download/commit/
> 84af661b1e5e110419f17dbf9295547c135a0cc5#diff-
> 217ea4d3217197ce4ece382e050a7302R26
>
> On Mon, May 15, 2017 at 3:14 PM, Maxim Solodovnik 
> wrote:
> > Thanks a lot for checking Martin,
> >
> > The issue seems to be caused by following code in *.html (reproducible
> > using quickstart)
> >
> > 
> > $(function() {
> >   Wicket.Event.subscribe(Wicket.Event.Topic.WebSocket.Opened,
> function() {
> > Wicket.WebSocket.send("socketConnected");
> >   });
> > });
> > 
> >
> > I guess I need to manually set missing headers in such call
> >
> > Can you please help to set necessary headers?
> >
> > On Mon, May 15, 2017 at 1:50 PM, Martin Grigorov 
> wrote:
> >> Hi Maxim,
> >>
> >> Just adding getRequestCycleListeners().add(new
> >> CsrfPreventionRequestCycleListener());
> >> to org.apache.wicket.examples.websocket.JSR356Application#init()
> doesn't
> >> lead to any error.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Mon, May 15, 2017 at 7:54 AM, Maxim Solodovnik  >
> >> wrote:
> >>
> >>> Hello Martin,
> >>>
> >>> were you able to take a look at it?
> >>> I was hoping to have M6 with working Csrf+WebSockets 
> >>>
> >>> On Fri, May 12, 2017 at 4:45 PM, Maxim Solodovnik <
> solomax...@gmail.com>
> >>> wrote:
> >>> > Thanks a million, Martin :)
> >>> >
> >>> > On Fri, May 12, 2017 at 4:34 PM, Martin Grigorov <
> mgrigo...@apache.org>
> >>> wrote:
> >>> >> Hi Maxim,
> >>> >>
> >>> >> I don't use this combination.
> >>> >> But I will try to test it soon and see what can be done.
> >>> >>
> >>> >> Martin Grigorov
> >>> >> Wicket Training and Consulting
> >>> >> https://twitter.com/mtgrigorov
> >>> >>
> >>> >> On Fri, May 12, 2017 at 11:00 AM, Maxim Solodovnik <
> >>> solomax...@gmail.com>
> >>> >> wrote:
> >>> >>
> >>> >>> Does anybody uses this filter?
> >>> >>>
> >>> >>> On Thu, May 11, 2017 at 10:44 AM, Maxim Solodovnik <
> >>> solomax...@gmail.com>
> >>> >>> wrote:
> >>> >>> > Hello All,
> >>> >>> >
> >>> >>> > just have tried to add CsrfPreventionRequestCycleListener to our
> >>> >>> application
> >>> >>> > everything seems to work except for Websockets :(
> >>> >>> >
> >>> >>> > Now I'm getting
> >>> >>> >
> >>> >>> > [INFO] [http-nio-0.0.0.0-5080-exec-9]
> >>> >>> > org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener
> -
> >>> >>> > Possible CSRF attack, request URL:
> >>> >>> > /openmeetings/wicket/websocket?pageId=1
> >>> >>> ajax-baseurl==OpenmeetingsApplication,
> >>> >>> > Origin: null, action: aborted with error 400 Origin does not
> >>> >>> > correspond to request
> >>> >>> > [WARN] [http-nio-0.0.0.0-5080-exec-9]
> >>> >>> > org.apache.wicket.protocol.ws.api.WebSocketResponse - An HTTP
> error
> >>> >>> > response in WebSocket communication would not be processed by the
> >>> >>> > browser! If you need to send the error code and message to the
> client
> >>> >>> > then configure custom WebSocketResponse via
> >>> >>> > WebSocketSettings#newWebSocketResponse() factory method and
> override
> >>> >>> > #sendError() method to write them in an appropriate format for
> your
> >>> >>> > application. The ignored error code is '400'

Re: inside inline frame

2017-05-15 Thread Claudia Hirt

Thanks for the answer.
Always nice to learn something new, but sadly this won't solve my problem. I 
will need both of the stylesheet files. Application developers shall bring 
their own css for their app and should not have to care about the design of the 
menu wrapped around. 
I'm looking for a way to seperate them so they don't get in each others way. 
Something like scoped css. 
But i think there won't be a wicket-way to solve this. It's more a css issue. 

> Am 14.05.2017 um 21:04 schrieb Martin Grigorov :
> 
> Hi,
> 
> Maybe a simpler solution would be to use custom IHeaderResponseDecorator
> that skips all CssHeaderItems contributed by the base module.
> If you can differentiate your application CssHeaderItems from the one from
> the base module, e.g. by package name, then I think this will work.
> See org.apache.wicket.markup.head.filter.FilteringHeaderResponse for
> inspiration.
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
>> On Fri, May 12, 2017 at 10:36 PM, Claudia Hirt  wrote:
>> 
>> Hi all,
>> 
>> is it possible to wrap a child page's markup inside an iframe?
>> 
>> The reason I want to do this:
>> My BasePage containing a header- and menu-panel is located in an artifact
>> used by several applications. These applications contain their own
>> stylesheets and I want to avoid side effects like css of application
>> affecting my header-panel.
>> 
>> I think the only way to solve this would be to have the whole application
>> page inside an iframe, because using CSS namespaces via IDs would be a
>> hudge effort and be to risky.
>> 
>> Thanks in advance!
>> 
>> Best regards,
>> Claudia Hirt
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Balancer + HTTPS

2017-05-15 Thread Marcel Barbosa Pinto

Hi Martin,

I've found something that could be related, at this line below, a new Url
instance is created without being configured with the protocol. Is this URL
relative or absolute?

https://github.com/apache/wicket/blob/9e42a9548adb0da540e4e87d491f5824e778537e/wicket-core/src/main/java/org/apache/wicket/core/request/mapper/PageInstanceMapper.java#L129

I'll will try to debug the code later.
Thanks.




On Mon, May 15, 2017 at 3:56 AM, Martin Grigorov 
wrote:

> Hi,
>
> Put a breakpoint at org.apache.wicket.request.Url#getProtocol() and see
> what it returns.
> I guess the redirect is an absolute url and that's why it breaks.
> See org.apache.wicket.protocol.http.servlet.ServletWebResponse#
> sendRedirect
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, May 15, 2017 at 5:01 AM, Marcel Barbosa Pinto <
> marcel.po...@gmail.com> wrote:
>
> > Hi,
> >
> > I am using a balancer which sends the X-Forwarded-Proto header to my
> Wicket
> > application.
> >
> > I`ve added the following filters:
> >
> >  getFilterFactoryManager()
> > > .addSecuredRemoteAddressRequestWrapperFactory(null)
> > > .addXForwardedRequestWrapperFactory(null);
> > >
> >
> > And the HttpsMapper:
> >
> > setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
> > > HttpsConfig())
> > >
> >
> >
> > And the following init-param into web.xml
> >
> > 
> > >   protocolHeader
> > >   X-Forwarded-Proto
> > >  
> > >
> >
> >
> > When I debug I can see that the header is working inside a
> > RequestCycleListener
> >
> > HttpServletRequest req = (HttpServletRequest)
> > > cycle.getRequest().getContainerRequest();
> > > System.out.println("-->" + req.getScheme() + " ==" +
> > > req.getHeader("X-Forwarded-Proto");
> > >
> >
> >
> > The problem occurs when some versioned page is created and wicket
> redirect
> > it to the same URL but with the HTTP:// instead, for example:
> >
> > *https://*www.wicket.com/statefullPage
> > -> Response header: 302 (Location: *http://*www.wicket.com/
> > statefullPage*?1*
> > )
> >
> > If I change it back to HTTPS it works:
> >
> > *https://*www.wicket.com/statefullPage
> > *?1*
> > *-> *Response 200 OK
> >
> > I believe that in some redirection logic the original schema is being
> lost
> > somehow, during page versioning.
> > This problem only occurs when using the "X-Forwarded-Proto" header
> >
> > Using Wicket 7.6.0
> > Any suggestions?
> >
> > Thanks!
> >
>



-- 

Marcel Barbosa Pinto
55 11 98255 8288

Re: WebSockets and CsrfPreventionRequestCycleListener

2017-05-15 Thread Maxim Solodovnik

Example project demonstrating it is here:
https://github.com/solomax/ajax-download


html with WebSocket.send:
https://github.com/solomax/ajax-download/commit/84af661b1e5e110419f17dbf9295547c135a0cc5#diff-217ea4d3217197ce4ece382e050a7302R26

On Mon, May 15, 2017 at 3:14 PM, Maxim Solodovnik  wrote:
> Thanks a lot for checking Martin,
>
> The issue seems to be caused by following code in *.html (reproducible
> using quickstart)
>
> 
> $(function() {
>   Wicket.Event.subscribe(Wicket.Event.Topic.WebSocket.Opened, function() {
> Wicket.WebSocket.send("socketConnected");
>   });
> });
> 
>
> I guess I need to manually set missing headers in such call
>
> Can you please help to set necessary headers?
>
> On Mon, May 15, 2017 at 1:50 PM, Martin Grigorov  wrote:
>> Hi Maxim,
>>
>> Just adding getRequestCycleListeners().add(new
>> CsrfPreventionRequestCycleListener());
>> to org.apache.wicket.examples.websocket.JSR356Application#init() doesn't
>> lead to any error.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, May 15, 2017 at 7:54 AM, Maxim Solodovnik 
>> wrote:
>>
>>> Hello Martin,
>>>
>>> were you able to take a look at it?
>>> I was hoping to have M6 with working Csrf+WebSockets 
>>>
>>> On Fri, May 12, 2017 at 4:45 PM, Maxim Solodovnik 
>>> wrote:
>>> > Thanks a million, Martin :)
>>> >
>>> > On Fri, May 12, 2017 at 4:34 PM, Martin Grigorov 
>>> wrote:
>>> >> Hi Maxim,
>>> >>
>>> >> I don't use this combination.
>>> >> But I will try to test it soon and see what can be done.
>>> >>
>>> >> Martin Grigorov
>>> >> Wicket Training and Consulting
>>> >> https://twitter.com/mtgrigorov
>>> >>
>>> >> On Fri, May 12, 2017 at 11:00 AM, Maxim Solodovnik <
>>> solomax...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Does anybody uses this filter?
>>> >>>
>>> >>> On Thu, May 11, 2017 at 10:44 AM, Maxim Solodovnik <
>>> solomax...@gmail.com>
>>> >>> wrote:
>>> >>> > Hello All,
>>> >>> >
>>> >>> > just have tried to add CsrfPreventionRequestCycleListener to our
>>> >>> application
>>> >>> > everything seems to work except for Websockets :(
>>> >>> >
>>> >>> > Now I'm getting
>>> >>> >
>>> >>> > [INFO] [http-nio-0.0.0.0-5080-exec-9]
>>> >>> > org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener -
>>> >>> > Possible CSRF attack, request URL:
>>> >>> > /openmeetings/wicket/websocket?pageId=1
>>> >>> ajax-baseurl==OpenmeetingsApplication,
>>> >>> > Origin: null, action: aborted with error 400 Origin does not
>>> >>> > correspond to request
>>> >>> > [WARN] [http-nio-0.0.0.0-5080-exec-9]
>>> >>> > org.apache.wicket.protocol.ws.api.WebSocketResponse - An HTTP error
>>> >>> > response in WebSocket communication would not be processed by the
>>> >>> > browser! If you need to send the error code and message to the client
>>> >>> > then configure custom WebSocketResponse via
>>> >>> > WebSocketSettings#newWebSocketResponse() factory method and override
>>> >>> > #sendError() method to write them in an appropriate format for your
>>> >>> > application. The ignored error code is '400' and the message: 'Origin
>>> >>> > does not correspond to request'.
>>> >>> >
>>> >>> > in the logs ...
>>> >>> > What should I do to set Origin for Websockets?
>>> >>> >
>>> >>> > --
>>> >>> > WBR
>>> >>> > Maxim aka solomax
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> WBR
>>> >>> Maxim aka solomax
>>> >>>
>>> >>> -
>>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> > --
>>> > WBR
>>> > Maxim aka solomax
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>
>
>
> --
> WBR
> Maxim aka solomax



-- 
WBR
Maxim aka solomax

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: WebSockets and CsrfPreventionRequestCycleListener

2017-05-15 Thread Maxim Solodovnik

Thanks a lot for checking Martin,

The issue seems to be caused by following code in *.html (reproducible
using quickstart)


$(function() {
  Wicket.Event.subscribe(Wicket.Event.Topic.WebSocket.Opened, function() {
Wicket.WebSocket.send("socketConnected");
  });
});


I guess I need to manually set missing headers in such call

Can you please help to set necessary headers?

On Mon, May 15, 2017 at 1:50 PM, Martin Grigorov  wrote:
> Hi Maxim,
>
> Just adding getRequestCycleListeners().add(new
> CsrfPreventionRequestCycleListener());
> to org.apache.wicket.examples.websocket.JSR356Application#init() doesn't
> lead to any error.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, May 15, 2017 at 7:54 AM, Maxim Solodovnik 
> wrote:
>
>> Hello Martin,
>>
>> were you able to take a look at it?
>> I was hoping to have M6 with working Csrf+WebSockets 
>>
>> On Fri, May 12, 2017 at 4:45 PM, Maxim Solodovnik 
>> wrote:
>> > Thanks a million, Martin :)
>> >
>> > On Fri, May 12, 2017 at 4:34 PM, Martin Grigorov 
>> wrote:
>> >> Hi Maxim,
>> >>
>> >> I don't use this combination.
>> >> But I will try to test it soon and see what can be done.
>> >>
>> >> Martin Grigorov
>> >> Wicket Training and Consulting
>> >> https://twitter.com/mtgrigorov
>> >>
>> >> On Fri, May 12, 2017 at 11:00 AM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> >> wrote:
>> >>
>> >>> Does anybody uses this filter?
>> >>>
>> >>> On Thu, May 11, 2017 at 10:44 AM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> >>> wrote:
>> >>> > Hello All,
>> >>> >
>> >>> > just have tried to add CsrfPreventionRequestCycleListener to our
>> >>> application
>> >>> > everything seems to work except for Websockets :(
>> >>> >
>> >>> > Now I'm getting
>> >>> >
>> >>> > [INFO] [http-nio-0.0.0.0-5080-exec-9]
>> >>> > org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener -
>> >>> > Possible CSRF attack, request URL:
>> >>> > /openmeetings/wicket/websocket?pageId=1
>> >>> ajax-baseurl==OpenmeetingsApplication,
>> >>> > Origin: null, action: aborted with error 400 Origin does not
>> >>> > correspond to request
>> >>> > [WARN] [http-nio-0.0.0.0-5080-exec-9]
>> >>> > org.apache.wicket.protocol.ws.api.WebSocketResponse - An HTTP error
>> >>> > response in WebSocket communication would not be processed by the
>> >>> > browser! If you need to send the error code and message to the client
>> >>> > then configure custom WebSocketResponse via
>> >>> > WebSocketSettings#newWebSocketResponse() factory method and override
>> >>> > #sendError() method to write them in an appropriate format for your
>> >>> > application. The ignored error code is '400' and the message: 'Origin
>> >>> > does not correspond to request'.
>> >>> >
>> >>> > in the logs ...
>> >>> > What should I do to set Origin for Websockets?
>> >>> >
>> >>> > --
>> >>> > WBR
>> >>> > Maxim aka solomax
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> WBR
>> >>> Maxim aka solomax
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>>
>> >>>
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>



-- 
WBR
Maxim aka solomax

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Balancer + HTTPS

2017-05-15 Thread Martin Grigorov

Hi,

Put a breakpoint at org.apache.wicket.request.Url#getProtocol() and see
what it returns.
I guess the redirect is an absolute url and that's why it breaks.
See org.apache.wicket.protocol.http.servlet.ServletWebResponse#sendRedirect

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, May 15, 2017 at 5:01 AM, Marcel Barbosa Pinto <
marcel.po...@gmail.com> wrote:

> Hi,
>
> I am using a balancer which sends the X-Forwarded-Proto header to my Wicket
> application.
>
> I`ve added the following filters:
>
>  getFilterFactoryManager()
> > .addSecuredRemoteAddressRequestWrapperFactory(null)
> > .addXForwardedRequestWrapperFactory(null);
> >
>
> And the HttpsMapper:
>
> setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
> > HttpsConfig())
> >
>
>
> And the following init-param into web.xml
>
> 
> >   protocolHeader
> >   X-Forwarded-Proto
> >  
> >
>
>
> When I debug I can see that the header is working inside a
> RequestCycleListener
>
> HttpServletRequest req = (HttpServletRequest)
> > cycle.getRequest().getContainerRequest();
> > System.out.println("-->" + req.getScheme() + " ==" +
> > req.getHeader("X-Forwarded-Proto");
> >
>
>
> The problem occurs when some versioned page is created and wicket redirect
> it to the same URL but with the HTTP:// instead, for example:
>
> *https://*www.wicket.com/statefullPage
> -> Response header: 302 (Location: *http://*www.wicket.com/
> statefullPage*?1*
> )
>
> If I change it back to HTTPS it works:
>
> *https://*www.wicket.com/statefullPage
> *?1*
> *-> *Response 200 OK
>
> I believe that in some redirection logic the original schema is being lost
> somehow, during page versioning.
> This problem only occurs when using the "X-Forwarded-Proto" header
>
> Using Wicket 7.6.0
> Any suggestions?
>
> Thanks!
>

Re: WebSockets and CsrfPreventionRequestCycleListener

2017-05-15 Thread Martin Grigorov

Hi Maxim,

Just adding getRequestCycleListeners().add(new
CsrfPreventionRequestCycleListener());
to org.apache.wicket.examples.websocket.JSR356Application#init() doesn't
lead to any error.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, May 15, 2017 at 7:54 AM, Maxim Solodovnik 
wrote:

> Hello Martin,
>
> were you able to take a look at it?
> I was hoping to have M6 with working Csrf+WebSockets 
>
> On Fri, May 12, 2017 at 4:45 PM, Maxim Solodovnik 
> wrote:
> > Thanks a million, Martin :)
> >
> > On Fri, May 12, 2017 at 4:34 PM, Martin Grigorov 
> wrote:
> >> Hi Maxim,
> >>
> >> I don't use this combination.
> >> But I will try to test it soon and see what can be done.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Fri, May 12, 2017 at 11:00 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >> wrote:
> >>
> >>> Does anybody uses this filter?
> >>>
> >>> On Thu, May 11, 2017 at 10:44 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >>> wrote:
> >>> > Hello All,
> >>> >
> >>> > just have tried to add CsrfPreventionRequestCycleListener to our
> >>> application
> >>> > everything seems to work except for Websockets :(
> >>> >
> >>> > Now I'm getting
> >>> >
> >>> > [INFO] [http-nio-0.0.0.0-5080-exec-9]
> >>> > org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener -
> >>> > Possible CSRF attack, request URL:
> >>> > /openmeetings/wicket/websocket?pageId=1
> >>> ajax-baseurl==OpenmeetingsApplication,
> >>> > Origin: null, action: aborted with error 400 Origin does not
> >>> > correspond to request
> >>> > [WARN] [http-nio-0.0.0.0-5080-exec-9]
> >>> > org.apache.wicket.protocol.ws.api.WebSocketResponse - An HTTP error
> >>> > response in WebSocket communication would not be processed by the
> >>> > browser! If you need to send the error code and message to the client
> >>> > then configure custom WebSocketResponse via
> >>> > WebSocketSettings#newWebSocketResponse() factory method and override
> >>> > #sendError() method to write them in an appropriate format for your
> >>> > application. The ignored error code is '400' and the message: 'Origin
> >>> > does not correspond to request'.
> >>> >
> >>> > in the logs ...
> >>> > What should I do to set Origin for Websockets?
> >>> >
> >>> > --
> >>> > WBR
> >>> > Maxim aka solomax
> >>>
> >>>
> >>>
> >>> --
> >>> WBR
> >>> Maxim aka solomax
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
>
> --
> WBR
> Maxim aka solomax
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Balancer + HTTPS

Re: WebSockets and CsrfPreventionRequestCycleListener

Re: WebSockets and CsrfPreventionRequestCycleListener

Re: inside inline frame

Re: Balancer + HTTPS

Re: WebSockets and CsrfPreventionRequestCycleListener

Re: WebSockets and CsrfPreventionRequestCycleListener

Re: Balancer + HTTPS

Re: WebSockets and CsrfPreventionRequestCycleListener

9 matches

Site Navigation

Mail list logo

Footer information