You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by George Christman <gc...@cardaddy.com> on 2015/04/10 14:56:19 UTC
DefaultRequestExceptionHandler not redirect xhr request to a secure link
I'm using relative links throughout my application and allowing our reverse
proxy to handle our secure port forwarding.
I just discovered that DefaultRequestExceptionHandler on line 210 is
creating an absolute link for all xhr request.
https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
The problem I face with this is we need to have secure links and it's
creating an non secure absolute link. Is there a way to override this
behavior so that I don't need to depend on our reverse proxy to forward the
request?
Re: DefaultRequestExceptionHandler not redirect xhr request to a
secure link
Posted by George Christman <gc...@cardaddy.com>.
Created a JIRA issue yesterday :)
https://issues.apache.org/jira/browse/TAP5-2471
On Mon, Apr 13, 2015 at 12:30 PM, Dimitris Zenios <dimitris.zenios@gmail.com
> wrote:
> Tapestry itself does not contribute any configuration to the
> RequestExceptionHandler service.
>
> One of the project that contributes a configuration is tapestry-security
> "configuration.add(ShiroException.class,
> SecurityExceptionHandlerAssistant.class);"
>
> So if the exceptions you are testing are not of type ShiroException and you
> didnt do any contribution to RequestExceptionHandler then it will propagate
> to renderException
>
> What ever the case is it would be nice to create an issue to JIRA regarding
> the absoluteUrl because event if you didn't hit that part of code its still
> an issue that has to be fixed
>
> Thanks
> Dimitris Zenios
> On Mon, Apr 13, 2015 at 3:25 AM, George Christman <gchristman@cardaddy.com
> >
> wrote:
>
> > Thanks Kalle and yes I did try overriding the service with my own
> > implementation, however I must have been missing something some wheres
> > because the configuration always appeared to be empty triggering a
> > renderException.
> >
> > On Fri, Apr 10, 2015 at 7:14 PM, Kalle Korhonen <
> > kalle.o.korhonen@gmail.com>
> > wrote:
> >
> > > On Fri, Apr 10, 2015 at 5:56 AM, George Christman <
> > gchristman@cardaddy.com
> > > >
> > > wrote:
> > >
> > > > I'm using relative links throughout my application and allowing our
> > > reverse
> > > > proxy to handle our secure port forwarding.
> > > >
> > > > I just discovered that DefaultRequestExceptionHandler on line 210 is
> > > > creating an absolute link for all xhr request.
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
> > > >
> > > > The problem I face with this is we need to have secure links and it's
> > > > creating an non secure absolute link. Is there a way to override this
> > > > behavior so that I don't need to depend on our reverse proxy to
> forward
> > > the
> > > > request?
> > > >
> > >
> > > Obviously the DefaultRequestExceptionHandler can be replaced like the
> > name
> > > implies. But yes, please open an issue and I'll fix it.
> > >
> > > @Dimitris, yes your analysis is completely correct, should have gone
> > > through it more carefully when I merged it in.
> > >
> > > Kalle
> > >
> >
> >
> >
> > --
> > George Christman
> > CEO
> > www.CarDaddy.com
> > P.O. Box 735
> > Johnstown, New York
> >
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
Re: DefaultRequestExceptionHandler not redirect xhr request to a
secure link
Posted by Dimitris Zenios <di...@gmail.com>.
Tapestry itself does not contribute any configuration to the
RequestExceptionHandler service.
One of the project that contributes a configuration is tapestry-security
"configuration.add(ShiroException.class,
SecurityExceptionHandlerAssistant.class);"
So if the exceptions you are testing are not of type ShiroException and you
didnt do any contribution to RequestExceptionHandler then it will propagate
to renderException
What ever the case is it would be nice to create an issue to JIRA regarding
the absoluteUrl because event if you didn't hit that part of code its still
an issue that has to be fixed
Thanks
Dimitris Zenios
On Mon, Apr 13, 2015 at 3:25 AM, George Christman <gc...@cardaddy.com>
wrote:
> Thanks Kalle and yes I did try overriding the service with my own
> implementation, however I must have been missing something some wheres
> because the configuration always appeared to be empty triggering a
> renderException.
>
> On Fri, Apr 10, 2015 at 7:14 PM, Kalle Korhonen <
> kalle.o.korhonen@gmail.com>
> wrote:
>
> > On Fri, Apr 10, 2015 at 5:56 AM, George Christman <
> gchristman@cardaddy.com
> > >
> > wrote:
> >
> > > I'm using relative links throughout my application and allowing our
> > reverse
> > > proxy to handle our secure port forwarding.
> > >
> > > I just discovered that DefaultRequestExceptionHandler on line 210 is
> > > creating an absolute link for all xhr request.
> > >
> > >
> > >
> >
> https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
> > >
> > > The problem I face with this is we need to have secure links and it's
> > > creating an non secure absolute link. Is there a way to override this
> > > behavior so that I don't need to depend on our reverse proxy to forward
> > the
> > > request?
> > >
> >
> > Obviously the DefaultRequestExceptionHandler can be replaced like the
> name
> > implies. But yes, please open an issue and I'll fix it.
> >
> > @Dimitris, yes your analysis is completely correct, should have gone
> > through it more carefully when I merged it in.
> >
> > Kalle
> >
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
Re: DefaultRequestExceptionHandler not redirect xhr request to a
secure link
Posted by George Christman <gc...@cardaddy.com>.
Thanks Kalle and yes I did try overriding the service with my own
implementation, however I must have been missing something some wheres
because the configuration always appeared to be empty triggering a
renderException.
On Fri, Apr 10, 2015 at 7:14 PM, Kalle Korhonen <ka...@gmail.com>
wrote:
> On Fri, Apr 10, 2015 at 5:56 AM, George Christman <gchristman@cardaddy.com
> >
> wrote:
>
> > I'm using relative links throughout my application and allowing our
> reverse
> > proxy to handle our secure port forwarding.
> >
> > I just discovered that DefaultRequestExceptionHandler on line 210 is
> > creating an absolute link for all xhr request.
> >
> >
> >
> https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
> >
> > The problem I face with this is we need to have secure links and it's
> > creating an non secure absolute link. Is there a way to override this
> > behavior so that I don't need to depend on our reverse proxy to forward
> the
> > request?
> >
>
> Obviously the DefaultRequestExceptionHandler can be replaced like the name
> implies. But yes, please open an issue and I'll fix it.
>
> @Dimitris, yes your analysis is completely correct, should have gone
> through it more carefully when I merged it in.
>
> Kalle
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
Re: DefaultRequestExceptionHandler not redirect xhr request to a
secure link
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Apr 10, 2015 at 5:56 AM, George Christman <gc...@cardaddy.com>
wrote:
> I'm using relative links throughout my application and allowing our reverse
> proxy to handle our secure port forwarding.
>
> I just discovered that DefaultRequestExceptionHandler on line 210 is
> creating an absolute link for all xhr request.
>
>
> https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
>
> The problem I face with this is we need to have secure links and it's
> creating an non secure absolute link. Is there a way to override this
> behavior so that I don't need to depend on our reverse proxy to forward the
> request?
>
Obviously the DefaultRequestExceptionHandler can be replaced like the name
implies. But yes, please open an issue and I'll fix it.
@Dimitris, yes your analysis is completely correct, should have gone
through it more carefully when I merged it in.
Kalle
Re: DefaultRequestExceptionHandler not redirect xhr request to a
secure link
Posted by Dimitris Zenios <di...@gmail.com>.
Hi
I think you are right
It should be link.toRedirectURI instead of toAbsoluteURI just like
AjaxLinkComponentEventResultProcessor does.
I cannot find a real reason why it should be toAbsoluteUrl. Also by looking
at tapestry-core source code this is the only case that toAbsoluteUrl is
called from tapestrys source code .There is another one inside form (action
link creation) but that was intentionally and controlled by Secure
parameter.
The addition of toAbsoluteUrl was done as part of the TAP5-1833.Merge
functionality of Tynamo.org's
tapestry-exceptionpage module with the built-in ExceptionHandler
On Fri, Apr 10, 2015 at 3:56 PM, George Christman <gc...@cardaddy.com>
wrote:
> I'm using relative links throughout my application and allowing our reverse
> proxy to handle our secure port forwarding.
>
> I just discovered that DefaultRequestExceptionHandler on line 210 is
> creating an absolute link for all xhr request.
>
>
> https://github.com/apache/tapestry-5/blob/840533975a33d9094789bc09e40557a5c3ec7ba8/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.java
>
> The problem I face with this is we need to have secure links and it's
> creating an non secure absolute link. Is there a way to override this
> behavior so that I don't need to depend on our reverse proxy to forward the
> request?
>