You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Olger Warnier <ol...@xs4all.nl> on 2009/07/26 21:46:48 UTC
Re: UnauthorizedActionException wrapped in an InvalidUrlException -> how to deal with it ?
Hi Igor,
> if the form is disabled why is it allowed to be submitted?
In a test you can ;)
When you know what to submit, it is possible to submit those values
without a page, although I can imagine that it is quite hard to
achieve due to the way wicket handles form variables and stuff (via
the session).
Even with that in mind, I wonder if it is possible to have the
UnauthorizedException thrown directly (without the InvalidUrlException).
Kind Regards,
Olger
>
> -igor
>
> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl>
> wrote:
>> Hi Developers,
>>
>> Slowly but surely I move through the tests of the wicket security
>> framework.
>> In one test, the SecureFormTest, i ran into some strange behaviour.
>> It starts with an exception like this:
>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>> org.apache.wicket.authorization.UnauthorizedActionException:
>> Component
>> [MarkupContainer [Component id = form]] does not permit action ENABLE
>>
>> (note, the test is commented in order to prevent build failures)
>>
>> There is a secureform that has no rights to be filled an submitted.
>> Normal
>> behaviour till now was the return of a login page. In some cases I
>> found the
>> return of the UnauthorizedActionException - all fine till now.
>> (running
>> 1.4-rc7)
>> In this test though, I there is no redirection to a Login Page and
>> I can't
>> catch the UnauthorizedActionException. This started my quest into the
>> originating throws, this happens to be the throw of an
>> InvalidUrlException
>> in WebRequestCycleProcessor (line 248 and on)
>>
>> catch (WicketRuntimeException e)
>> {
>> // we need to let page expired exception
>> sift through
>> instead of covering it up
>>
>> if (e instanceof PageExpiredException)
>> {
>> throw e;
>> }
>> else if (e.getCause() instanceof
>> PageExpiredException)
>> {
>> throw e;
>> }
>> else
>> {
>> throw new InvalidUrlException(e);
>> }
>> }
>>
>> The UnauthorizedActionException is catched here and thereafter thrown
>> wrapped in an InvalidUrlException.
>>
>> This is not the end of it, the RequestCycle catches this exception
>> and has
>> some logic for it (line 1337 starting) :
>>
>> catch (RuntimeException e)
>> {
>> /*
>> * check if the raised exception wraps an
>> abort
>> exception. if so, it is probably wise to
>> * unwrap and rethrow the abort exception
>> */
>> Throwable cause = e.getCause();
>> while (cause != null)
>> {
>> if (cause instanceof AbortException)
>> {
>> throw ((AbortException)cause);
>> }
>> cause = cause.getCause();
>> }
>> if (!handlingException)
>> {
>> // set step manually to handle
>> exception
>> handlingException = true;
>>
>> // probably our last chance the
>> exception can
>> be logged.
>> // Note that a PageExpiredException
>> should
>> not be logged, because
>> // it's not an internal error
>> if (!(e instanceof
>> PageExpiredException))
>> {
>> logRuntimeException(e);
>> }
>>
>> // try to play nicely and let the
>> request
>> processor handle the
>> // exception response. If that
>> doesn't work,
>> any runtime exception
>> // will automatically be bubbled up
>> if (processor != null)
>> {
>> processor.respond(e, this);
>> }
>> }
>> else..........
>>
>> The exception runs through the cause loop, ending with a null
>> cause, and
>> continues to be logged and thereafter triggers a
>> processor.respond(e,this)
>> based on the InvalidUrlException.
>>
>> This one is catched by the AbstractRequestCycleProcessor, doing the
>> following (line 116 and on):
>>
>> final Application application = Application.get();
>> final IExceptionSettings settings =
>> application.getExceptionSettings();
>> final Page responsePage =
>> requestCycle.getResponsePage();
>>
>> Page override = onRuntimeException(responsePage, e);
>> if (override != null)
>> {
>> throw new RestartResponseException(override);
>> }
>> else if (e instanceof AuthorizationException)
>> {
>> // are authorization exceptions always
>> thrown before
>> the real
>> // render?
>> // else we need to make a page (see below)
>> or set it
>> hard to a
>> // redirect.
>> Class<? extends Page> accessDeniedPageClass =
>> application.getApplicationSettings()
>> .getAccessDeniedPage();
>>
>> throw new
>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>> }
>> else if (e instanceof PageExpiredException)
>> {
>> Class<? extends Page>
>> pageExpiredErrorPageClass =
>> application.getApplicationSettings()
>> .getPageExpiredErrorPage();
>>
>> As you can see, this class expects a AuthorizationException, but
>> the "e" in
>> question is an InvalidUrlException with as cause a
>> UnauthorizedActionException.
>>
>> I could fix this in wicket-security by checking the
>> InvalidUrlExceptions
>> somehow ( I assume using the onRuntimeException) for this cause and
>> redirect
>> to a unauthorized page, access denied page (or something), but I'd
>> like to
>> see what the best option is here.
>>
>> 1) WebRequestCycleProcessor does not rethrow the
>> WicketRuntimeException in
>> all cases, why is that ?
>> Is it an option to rethrow when there is a unauthorized type of
>> exception
>> here ?
>> 2) RequestCycle is doing nothing specific for this matter, so I
>> expect no
>> changes here
>> 3) AbstractRequestCycleProcessor checks for the authorization
>> exception, it
>> seems to me that that will never come (it is rethrown as invalidurl
>> in 1)
>>
>> Do I miss something here ?
>> If not, I would say that the UnAuthorizedExceptions should be
>> rethrown as
>> such at the WebRequestCycleProcessor.
>>
>> Kind Regards,
>>
>> Olger
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException -> how to deal with it ?
Posted by Olger Warnier <ol...@xs4all.nl>.
Well, I'll add that to the WaspWebApplication and check if that will do.
Thanks.
I'll check
On 27 jul 2009, at 12:37, Alex Objelean wrote:
>
>
> You can treat runtime exceptions by overriding newRequestCycle
> method of
> your Application class...
> @Override
> public Page onRuntimeException(final Page page, final
> RuntimeException e)
> {
> if (e instanceof InvalidUrlException) {
> //redirect to 404
> } else {
> return super.onRuntimeException(page, e);
> }
> }
>
>
> Olger Warnier-2 wrote:
>>
>> Sorry to keep on buggin over this, I try to understand what is the
>> best option to plugin the unauthorized type of exceptions into the
>> wicket framework.
>> It seems (maybe because of lack of understanding) that the
>> UnAuthorizedException handling can't work as it is now.
>> Now to move on:
>>
>> I've read the RFE Alex sent.
>>
>> As you create a more specific extension of the runtime exception, it
>> will be wrapped by the WebRequestCycleProcessor to an
>> InvalidURLException.
>>
>> How do you make sure that it will show the 404 ? (or is that default
>> for the InvalidURLException ?)
>>
>> It might be an idea to have some kind of exception resolvement at the
>> spot where this decision is made. (I don't know where that is, I have
>> seen hints that this is already done somehow and you are able to
>> override it. ) and throw runtime exceptions as is to that level. By
>> registering exception handler pages you have the option to customize
>> the behaviour.
>>
>> If I like to do that in the current situation, I need to handle the
>> InvalidUrlException, check the cause and do something only in the
>> case
>> I'd like to process (Unauthorized)
>> What to do with the other causes of the InvalidUrl then ?
>>
>>
>> Kind Regards,
>>
>> Olger
>>
>>
>> On 27 jul 2009, at 11:41, Alex Objelean wrote:
>>
>>>
>>>
>>> This is the link of the RFE:
>>> https://issues.apache.org/jira/browse/WICKET-2307
>>>
>>>
>>> Olger Warnier-2 wrote:
>>>>
>>>> On 26 jul 2009, at 22:59, Alex Objelean wrote:
>>>>>
>>>>> If you think this would help, then you could remove
>>>>> InvalidUrlException and
>>>>> invalidate the jira RFE created by me... I don't think this would
>>>>> heart
>>>>> anyone...
>>>> Intresting, I assume that it is of value to have this construction,
>>>> could you give me the link to the RFE ?
>>>>
>>>> At any time, somehing was a WicketRuntimeException and only a
>>>> PageExpired (original or as cause) is now rethrown. All others are
>>>> wrapped.
>>>> Is there a case that in the AbstractRequestCycleProcessor the
>>>> following works then ?
>>>>
>>>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>>>> {
>>>>>>>>>>> // are authorization exceptions always
>>>>>>>>>>> thrown
>>>>
>>>> Kind Regards,
>>>>
>>>> Olger
>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>>>
>>>>>> my point is that this case is on the fence.
>>>>>>
>>>>>> it is an invalid url, and it is a security violation. so which
>>>>>> one
>>>>>> should take precendence?
>>>>>>
>>>>>> my other concern is that we would have to maintain a long list of
>>>>>> exceptions that should be passed through, which becomes a pita.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objelean@yahoo.com
>>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> I just want to remind the reason why the InvalidUrlException was
>>>>>>> introduced:
>>>>>>> to avoid situations when user would tweak somehow the url and
>>>>>>> get
>>>>>>> the
>>>>>>> InternalError Page... I introduced a request for enhancement
>>>>>>> for
>>>>>>> InvalidUrlException feature and if there are any problems
>>>>>>> related
>>>>>>> to it,
>>>>>>> you
>>>>>>> can blame me..:(
>>>>>>>
>>>>>>> Alex Objelean
>>>>>>>
>>>>>>>
>>>>>>> igor.vaynberg wrote:
>>>>>>>>
>>>>>>>> then we are getting in a debate of what use an
>>>>>>>> invalidurlexception
>>>>>>>> really is. if we forward page expired and a bunch of other
>>>>>>>> exceptions,
>>>>>>>> why do we even need an invalidurlexception...
>>>>>>>>
>>>>>>>> the point is the user has submitted a form that they should not
>>>>>>>> have
>>>>>>>> been able to, it is an invalid url...
>>>>>>>>
>>>>>>>> i dont know off the top of my head what the best approach is.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger
>>>>>>>> Warnier<ol...@xs4all.nl>
>>>>>>>> wrote:
>>>>>>>>> Hi Igor,
>>>>>>>>>
>>>>>>>>>> if the form is disabled why is it allowed to be submitted?
>>>>>>>>>
>>>>>>>>> In a test you can ;)
>>>>>>>>> When you know what to submit, it is possible to submit those
>>>>>>>>> values
>>>>>>>>> without
>>>>>>>>> a page, although I can imagine that it is quite hard to
>>>>>>>>> achieve
>>>>>>>>> due to
>>>>>>>>> the
>>>>>>>>> way wicket handles form variables and stuff (via the session).
>>>>>>>>>
>>>>>>>>> Even with that in mind, I wonder if it is possible to have
>>>>>>>>> the
>>>>>>>>> UnauthorizedException thrown directly (without the
>>>>>>>>> InvalidUrlException).
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>>
>>>>>>>>> Olger
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -igor
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger
>>>>>>>>>> Warnier<ol...@xs4all.nl>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Developers,
>>>>>>>>>>>
>>>>>>>>>>> Slowly but surely I move through the tests of the wicket
>>>>>>>>>>> security
>>>>>>>>>>> framework.
>>>>>>>>>>> In one test, the SecureFormTest, i ran into some strange
>>>>>>>>>>> behaviour.
>>>>>>>>>>> It starts with an exception like this:
>>>>>>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>>>>>>> Component
>>>>>>>>>>> [MarkupContainer [Component id = form]] does not permit
>>>>>>>>>>> action
>>>>>>>>>>> ENABLE
>>>>>>>>>>>
>>>>>>>>>>> (note, the test is commented in order to prevent build
>>>>>>>>>>> failures)
>>>>>>>>>>>
>>>>>>>>>>> There is a secureform that has no rights to be filled an
>>>>>>>>>>> submitted.
>>>>>>>>>>> Normal
>>>>>>>>>>> behaviour till now was the return of a login page. In some
>>>>>>>>>>> cases I
>>>>>>>>>>> found
>>>>>>>>>>> the
>>>>>>>>>>> return of the UnauthorizedActionException - all fine till
>>>>>>>>>>> now.
>>>>>>>>>>> (running
>>>>>>>>>>> 1.4-rc7)
>>>>>>>>>>> In this test though, I there is no redirection to a Login
>>>>>>>>>>> Page
>>>>>>>>>>> and I
>>>>>>>>>>> can't
>>>>>>>>>>> catch the UnauthorizedActionException. This started my quest
>>>>>>>>>>> into the
>>>>>>>>>>> originating throws, this happens to be the throw of an
>>>>>>>>>>> InvalidUrlException
>>>>>>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>>>>>>
>>>>>>>>>>> catch (WicketRuntimeException e)
>>>>>>>>>>> {
>>>>>>>>>>> // we need to let page expired exception
>>>>>>>>>>> sift
>>>>>>>>>>> through
>>>>>>>>>>> instead of covering it up
>>>>>>>>>>>
>>>>>>>>>>> if (e instanceof PageExpiredException)
>>>>>>>>>>> {
>>>>>>>>>>> throw e;
>>>>>>>>>>> }
>>>>>>>>>>> else if (e.getCause() instanceof
>>>>>>>>>>> PageExpiredException)
>>>>>>>>>>> {
>>>>>>>>>>> throw e;
>>>>>>>>>>> }
>>>>>>>>>>> else
>>>>>>>>>>> {
>>>>>>>>>>> throw new
>>>>>>>>>>> InvalidUrlException(e);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The UnauthorizedActionException is catched here and
>>>>>>>>>>> thereafter
>>>>>>>>>>> thrown
>>>>>>>>>>> wrapped in an InvalidUrlException.
>>>>>>>>>>>
>>>>>>>>>>> This is not the end of it, the RequestCycle catches this
>>>>>>>>>>> exception
>>>>>>>>>>> and
>>>>>>>>>>> has
>>>>>>>>>>> some logic for it (line 1337 starting) :
>>>>>>>>>>>
>>>>>>>>>>> catch (RuntimeException e)
>>>>>>>>>>> {
>>>>>>>>>>> /*
>>>>>>>>>>> * check if the raised exception wraps
>>>>>>>>>>> an abort
>>>>>>>>>>> exception. if so, it is probably wise to
>>>>>>>>>>> * unwrap and rethrow the abort
>>>>>>>>>>> exception
>>>>>>>>>>> */
>>>>>>>>>>> Throwable cause = e.getCause();
>>>>>>>>>>> while (cause != null)
>>>>>>>>>>> {
>>>>>>>>>>> if (cause instanceof
>>>>>>>>>>> AbortException)
>>>>>>>>>>> {
>>>>>>>>>>> throw
>>>>>>>>>>> ((AbortException)cause);
>>>>>>>>>>> }
>>>>>>>>>>> cause = cause.getCause();
>>>>>>>>>>> }
>>>>>>>>>>> if (!handlingException)
>>>>>>>>>>> {
>>>>>>>>>>> // set step manually to handle
>>>>>>>>>>> exception
>>>>>>>>>>> handlingException = true;
>>>>>>>>>>>
>>>>>>>>>>> // probably our last chance the
>>>>>>>>>>> exception
>>>>>>>>>>> can
>>>>>>>>>>> be logged.
>>>>>>>>>>> // Note that a
>>>>>>>>>>> PageExpiredException
>>>>>>>>>>> should
>>>>>>>>>>> not be logged, because
>>>>>>>>>>> // it's not an internal error
>>>>>>>>>>> if (!(e instanceof
>>>>>>>>>>> PageExpiredException))
>>>>>>>>>>> {
>>>>>>>>>>> logRuntimeException(e);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> // try to play nicely and let
>>>>>>>>>>> the
>>>>>>>>>>> request
>>>>>>>>>>> processor handle the
>>>>>>>>>>> // exception response. If that
>>>>>>>>>>> doesn't
>>>>>>>>>>> work,
>>>>>>>>>>> any runtime exception
>>>>>>>>>>> // will automatically be bubbled
>>>>>>>>>>> up
>>>>>>>>>>> if (processor != null)
>>>>>>>>>>> {
>>>>>>>>>>> processor.respond(e,
>>>>>>>>>>> this);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> else..........
>>>>>>>>>>>
>>>>>>>>>>> The exception runs through the cause loop, ending with a
>>>>>>>>>>> null
>>>>>>>>>>> cause,
>>>>>>>>>>> and
>>>>>>>>>>> continues to be logged and thereafter triggers a
>>>>>>>>>>> processor.respond(e,this)
>>>>>>>>>>> based on the InvalidUrlException.
>>>>>>>>>>>
>>>>>>>>>>> This one is catched by the AbstractRequestCycleProcessor,
>>>>>>>>>>> doing the
>>>>>>>>>>> following (line 116 and on):
>>>>>>>>>>>
>>>>>>>>>>> final Application application =
>>>>>>>>>>> Application.get();
>>>>>>>>>>> final IExceptionSettings settings =
>>>>>>>>>>> application.getExceptionSettings();
>>>>>>>>>>> final Page responsePage =
>>>>>>>>>>> requestCycle.getResponsePage();
>>>>>>>>>>>
>>>>>>>>>>> Page override = onRuntimeException(responsePage,
>>>>>>>>>>> e);
>>>>>>>>>>> if (override != null)
>>>>>>>>>>> {
>>>>>>>>>>> throw new
>>>>>>>>>>> RestartResponseException(override);
>>>>>>>>>>> }
>>>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>>>> {
>>>>>>>>>>> // are authorization exceptions always
>>>>>>>>>>> thrown
>>>>>>>>>>> before
>>>>>>>>>>> the real
>>>>>>>>>>> // render?
>>>>>>>>>>> // else we need to make a page (see
>>>>>>>>>>> below) or
>>>>>>>>>>> set
>>>>>>>>>>> it
>>>>>>>>>>> hard to a
>>>>>>>>>>> // redirect.
>>>>>>>>>>> Class<? extends Page>
>>>>>>>>>>> accessDeniedPageClass =
>>>>>>>>>>> application.getApplicationSettings()
>>>>>>>>>>> .getAccessDeniedPage();
>>>>>>>>>>>
>>>>>>>>>>> throw new
>>>>>>>>>>> RestartResponseAtInterceptPageException
>>>>>>>>>>> (accessDeniedPageClass);
>>>>>>>>>>> }
>>>>>>>>>>> else if (e instanceof PageExpiredException)
>>>>>>>>>>> {
>>>>>>>>>>> Class<? extends Page>
>>>>>>>>>>> pageExpiredErrorPageClass
>>>>>>>>>>> =
>>>>>>>>>>> application.getApplicationSettings()
>>>>>>>>>>> .getPageExpiredErrorPage();
>>>>>>>>>>>
>>>>>>>>>>> As you can see, this class expects a AuthorizationException,
>>>>>>>>>>> but the
>>>>>>>>>>> "e"
>>>>>>>>>>> in
>>>>>>>>>>> question is an InvalidUrlException with as cause a
>>>>>>>>>>> UnauthorizedActionException.
>>>>>>>>>>>
>>>>>>>>>>> I could fix this in wicket-security by checking the
>>>>>>>>>>> InvalidUrlExceptions
>>>>>>>>>>> somehow ( I assume using the onRuntimeException) for this
>>>>>>>>>>> cause and
>>>>>>>>>>> redirect
>>>>>>>>>>> to a unauthorized page, access denied page (or something),
>>>>>>>>>>> but
>>>>>>>>>>> I'd
>>>>>>>>>>> like
>>>>>>>>>>> to
>>>>>>>>>>> see what the best option is here.
>>>>>>>>>>>
>>>>>>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>>>>>>> WicketRuntimeException
>>>>>>>>>>> in
>>>>>>>>>>> all cases, why is that ?
>>>>>>>>>>> Is it an option to rethrow when there is a unauthorized type
>>>>>>>>>>> of
>>>>>>>>>>> exception
>>>>>>>>>>> here ?
>>>>>>>>>>> 2) RequestCycle is doing nothing specific for this matter,
>>>>>>>>>>> so I
>>>>>>>>>>> expect
>>>>>>>>>>> no
>>>>>>>>>>> changes here
>>>>>>>>>>> 3) AbstractRequestCycleProcessor checks for the
>>>>>>>>>>> authorization
>>>>>>>>>>> exception,
>>>>>>>>>>> it
>>>>>>>>>>> seems to me that that will never come (it is rethrown as
>>>>>>>>>>> invalidurl
>>>>>>>>>>> in
>>>>>>>>>>> 1)
>>>>>>>>>>>
>>>>>>>>>>> Do I miss something here ?
>>>>>>>>>>> If not, I would say that the UnAuthorizedExceptions should
>>>>>>>>>>> be
>>>>>>>>>>> rethrown
>>>>>>>>>>> as
>>>>>>>>>>> such at the WebRequestCycleProcessor.
>>>>>>>>>>>
>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>
>>>>>>>>>>> Olger
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24677165.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24678283.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Alex Objelean <al...@yahoo.com>.
You can treat runtime exceptions by overriding newRequestCycle method of
your Application class...
@Override
public Page onRuntimeException(final Page page, final RuntimeException e)
{
if (e instanceof InvalidUrlException) {
//redirect to 404
} else {
return super.onRuntimeException(page, e);
}
}
Olger Warnier-2 wrote:
>
> Sorry to keep on buggin over this, I try to understand what is the
> best option to plugin the unauthorized type of exceptions into the
> wicket framework.
> It seems (maybe because of lack of understanding) that the
> UnAuthorizedException handling can't work as it is now.
> Now to move on:
>
> I've read the RFE Alex sent.
>
> As you create a more specific extension of the runtime exception, it
> will be wrapped by the WebRequestCycleProcessor to an
> InvalidURLException.
>
> How do you make sure that it will show the 404 ? (or is that default
> for the InvalidURLException ?)
>
> It might be an idea to have some kind of exception resolvement at the
> spot where this decision is made. (I don't know where that is, I have
> seen hints that this is already done somehow and you are able to
> override it. ) and throw runtime exceptions as is to that level. By
> registering exception handler pages you have the option to customize
> the behaviour.
>
> If I like to do that in the current situation, I need to handle the
> InvalidUrlException, check the cause and do something only in the case
> I'd like to process (Unauthorized)
> What to do with the other causes of the InvalidUrl then ?
>
>
> Kind Regards,
>
> Olger
>
>
> On 27 jul 2009, at 11:41, Alex Objelean wrote:
>
>>
>>
>> This is the link of the RFE:
>> https://issues.apache.org/jira/browse/WICKET-2307
>>
>>
>> Olger Warnier-2 wrote:
>>>
>>> On 26 jul 2009, at 22:59, Alex Objelean wrote:
>>>>
>>>> If you think this would help, then you could remove
>>>> InvalidUrlException and
>>>> invalidate the jira RFE created by me... I don't think this would
>>>> heart
>>>> anyone...
>>> Intresting, I assume that it is of value to have this construction,
>>> could you give me the link to the RFE ?
>>>
>>> At any time, somehing was a WicketRuntimeException and only a
>>> PageExpired (original or as cause) is now rethrown. All others are
>>> wrapped.
>>> Is there a case that in the AbstractRequestCycleProcessor the
>>> following works then ?
>>>
>>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>>> {
>>>>>>>>>> // are authorization exceptions always
>>>>>>>>>> thrown
>>>
>>> Kind Regards,
>>>
>>> Olger
>>>
>>>>
>>>> Alex
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> my point is that this case is on the fence.
>>>>>
>>>>> it is an invalid url, and it is a security violation. so which one
>>>>> should take precendence?
>>>>>
>>>>> my other concern is that we would have to maintain a long list of
>>>>> exceptions that should be passed through, which becomes a pita.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objelean@yahoo.com
>>>>>>
>>>>> wrote:
>>>>>>
>>>>>> I just want to remind the reason why the InvalidUrlException was
>>>>>> introduced:
>>>>>> to avoid situations when user would tweak somehow the url and get
>>>>>> the
>>>>>> InternalError Page... I introduced a request for enhancement for
>>>>>> InvalidUrlException feature and if there are any problems related
>>>>>> to it,
>>>>>> you
>>>>>> can blame me..:(
>>>>>>
>>>>>> Alex Objelean
>>>>>>
>>>>>>
>>>>>> igor.vaynberg wrote:
>>>>>>>
>>>>>>> then we are getting in a debate of what use an
>>>>>>> invalidurlexception
>>>>>>> really is. if we forward page expired and a bunch of other
>>>>>>> exceptions,
>>>>>>> why do we even need an invalidurlexception...
>>>>>>>
>>>>>>> the point is the user has submitted a form that they should not
>>>>>>> have
>>>>>>> been able to, it is an invalid url...
>>>>>>>
>>>>>>> i dont know off the top of my head what the best approach is.
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl>
>>>>>>> wrote:
>>>>>>>> Hi Igor,
>>>>>>>>
>>>>>>>>> if the form is disabled why is it allowed to be submitted?
>>>>>>>>
>>>>>>>> In a test you can ;)
>>>>>>>> When you know what to submit, it is possible to submit those
>>>>>>>> values
>>>>>>>> without
>>>>>>>> a page, although I can imagine that it is quite hard to achieve
>>>>>>>> due to
>>>>>>>> the
>>>>>>>> way wicket handles form variables and stuff (via the session).
>>>>>>>>
>>>>>>>> Even with that in mind, I wonder if it is possible to have the
>>>>>>>> UnauthorizedException thrown directly (without the
>>>>>>>> InvalidUrlException).
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>>
>>>>>>>> Olger
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -igor
>>>>>>>>>
>>>>>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger
>>>>>>>>> Warnier<ol...@xs4all.nl>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Developers,
>>>>>>>>>>
>>>>>>>>>> Slowly but surely I move through the tests of the wicket
>>>>>>>>>> security
>>>>>>>>>> framework.
>>>>>>>>>> In one test, the SecureFormTest, i ran into some strange
>>>>>>>>>> behaviour.
>>>>>>>>>> It starts with an exception like this:
>>>>>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>>>>>> Component
>>>>>>>>>> [MarkupContainer [Component id = form]] does not permit action
>>>>>>>>>> ENABLE
>>>>>>>>>>
>>>>>>>>>> (note, the test is commented in order to prevent build
>>>>>>>>>> failures)
>>>>>>>>>>
>>>>>>>>>> There is a secureform that has no rights to be filled an
>>>>>>>>>> submitted.
>>>>>>>>>> Normal
>>>>>>>>>> behaviour till now was the return of a login page. In some
>>>>>>>>>> cases I
>>>>>>>>>> found
>>>>>>>>>> the
>>>>>>>>>> return of the UnauthorizedActionException - all fine till now.
>>>>>>>>>> (running
>>>>>>>>>> 1.4-rc7)
>>>>>>>>>> In this test though, I there is no redirection to a Login Page
>>>>>>>>>> and I
>>>>>>>>>> can't
>>>>>>>>>> catch the UnauthorizedActionException. This started my quest
>>>>>>>>>> into the
>>>>>>>>>> originating throws, this happens to be the throw of an
>>>>>>>>>> InvalidUrlException
>>>>>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>>>>>
>>>>>>>>>> catch (WicketRuntimeException e)
>>>>>>>>>> {
>>>>>>>>>> // we need to let page expired exception
>>>>>>>>>> sift
>>>>>>>>>> through
>>>>>>>>>> instead of covering it up
>>>>>>>>>>
>>>>>>>>>> if (e instanceof PageExpiredException)
>>>>>>>>>> {
>>>>>>>>>> throw e;
>>>>>>>>>> }
>>>>>>>>>> else if (e.getCause() instanceof
>>>>>>>>>> PageExpiredException)
>>>>>>>>>> {
>>>>>>>>>> throw e;
>>>>>>>>>> }
>>>>>>>>>> else
>>>>>>>>>> {
>>>>>>>>>> throw new InvalidUrlException(e);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The UnauthorizedActionException is catched here and thereafter
>>>>>>>>>> thrown
>>>>>>>>>> wrapped in an InvalidUrlException.
>>>>>>>>>>
>>>>>>>>>> This is not the end of it, the RequestCycle catches this
>>>>>>>>>> exception
>>>>>>>>>> and
>>>>>>>>>> has
>>>>>>>>>> some logic for it (line 1337 starting) :
>>>>>>>>>>
>>>>>>>>>> catch (RuntimeException e)
>>>>>>>>>> {
>>>>>>>>>> /*
>>>>>>>>>> * check if the raised exception wraps
>>>>>>>>>> an abort
>>>>>>>>>> exception. if so, it is probably wise to
>>>>>>>>>> * unwrap and rethrow the abort exception
>>>>>>>>>> */
>>>>>>>>>> Throwable cause = e.getCause();
>>>>>>>>>> while (cause != null)
>>>>>>>>>> {
>>>>>>>>>> if (cause instanceof
>>>>>>>>>> AbortException)
>>>>>>>>>> {
>>>>>>>>>> throw
>>>>>>>>>> ((AbortException)cause);
>>>>>>>>>> }
>>>>>>>>>> cause = cause.getCause();
>>>>>>>>>> }
>>>>>>>>>> if (!handlingException)
>>>>>>>>>> {
>>>>>>>>>> // set step manually to handle
>>>>>>>>>> exception
>>>>>>>>>> handlingException = true;
>>>>>>>>>>
>>>>>>>>>> // probably our last chance the
>>>>>>>>>> exception
>>>>>>>>>> can
>>>>>>>>>> be logged.
>>>>>>>>>> // Note that a
>>>>>>>>>> PageExpiredException
>>>>>>>>>> should
>>>>>>>>>> not be logged, because
>>>>>>>>>> // it's not an internal error
>>>>>>>>>> if (!(e instanceof
>>>>>>>>>> PageExpiredException))
>>>>>>>>>> {
>>>>>>>>>> logRuntimeException(e);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // try to play nicely and let the
>>>>>>>>>> request
>>>>>>>>>> processor handle the
>>>>>>>>>> // exception response. If that
>>>>>>>>>> doesn't
>>>>>>>>>> work,
>>>>>>>>>> any runtime exception
>>>>>>>>>> // will automatically be bubbled
>>>>>>>>>> up
>>>>>>>>>> if (processor != null)
>>>>>>>>>> {
>>>>>>>>>> processor.respond(e,
>>>>>>>>>> this);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>> else..........
>>>>>>>>>>
>>>>>>>>>> The exception runs through the cause loop, ending with a null
>>>>>>>>>> cause,
>>>>>>>>>> and
>>>>>>>>>> continues to be logged and thereafter triggers a
>>>>>>>>>> processor.respond(e,this)
>>>>>>>>>> based on the InvalidUrlException.
>>>>>>>>>>
>>>>>>>>>> This one is catched by the AbstractRequestCycleProcessor,
>>>>>>>>>> doing the
>>>>>>>>>> following (line 116 and on):
>>>>>>>>>>
>>>>>>>>>> final Application application =
>>>>>>>>>> Application.get();
>>>>>>>>>> final IExceptionSettings settings =
>>>>>>>>>> application.getExceptionSettings();
>>>>>>>>>> final Page responsePage =
>>>>>>>>>> requestCycle.getResponsePage();
>>>>>>>>>>
>>>>>>>>>> Page override = onRuntimeException(responsePage,
>>>>>>>>>> e);
>>>>>>>>>> if (override != null)
>>>>>>>>>> {
>>>>>>>>>> throw new
>>>>>>>>>> RestartResponseException(override);
>>>>>>>>>> }
>>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>>> {
>>>>>>>>>> // are authorization exceptions always
>>>>>>>>>> thrown
>>>>>>>>>> before
>>>>>>>>>> the real
>>>>>>>>>> // render?
>>>>>>>>>> // else we need to make a page (see
>>>>>>>>>> below) or
>>>>>>>>>> set
>>>>>>>>>> it
>>>>>>>>>> hard to a
>>>>>>>>>> // redirect.
>>>>>>>>>> Class<? extends Page>
>>>>>>>>>> accessDeniedPageClass =
>>>>>>>>>> application.getApplicationSettings()
>>>>>>>>>> .getAccessDeniedPage();
>>>>>>>>>>
>>>>>>>>>> throw new
>>>>>>>>>> RestartResponseAtInterceptPageException
>>>>>>>>>> (accessDeniedPageClass);
>>>>>>>>>> }
>>>>>>>>>> else if (e instanceof PageExpiredException)
>>>>>>>>>> {
>>>>>>>>>> Class<? extends Page>
>>>>>>>>>> pageExpiredErrorPageClass
>>>>>>>>>> =
>>>>>>>>>> application.getApplicationSettings()
>>>>>>>>>> .getPageExpiredErrorPage();
>>>>>>>>>>
>>>>>>>>>> As you can see, this class expects a AuthorizationException,
>>>>>>>>>> but the
>>>>>>>>>> "e"
>>>>>>>>>> in
>>>>>>>>>> question is an InvalidUrlException with as cause a
>>>>>>>>>> UnauthorizedActionException.
>>>>>>>>>>
>>>>>>>>>> I could fix this in wicket-security by checking the
>>>>>>>>>> InvalidUrlExceptions
>>>>>>>>>> somehow ( I assume using the onRuntimeException) for this
>>>>>>>>>> cause and
>>>>>>>>>> redirect
>>>>>>>>>> to a unauthorized page, access denied page (or something), but
>>>>>>>>>> I'd
>>>>>>>>>> like
>>>>>>>>>> to
>>>>>>>>>> see what the best option is here.
>>>>>>>>>>
>>>>>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>>>>>> WicketRuntimeException
>>>>>>>>>> in
>>>>>>>>>> all cases, why is that ?
>>>>>>>>>> Is it an option to rethrow when there is a unauthorized type
>>>>>>>>>> of
>>>>>>>>>> exception
>>>>>>>>>> here ?
>>>>>>>>>> 2) RequestCycle is doing nothing specific for this matter,
>>>>>>>>>> so I
>>>>>>>>>> expect
>>>>>>>>>> no
>>>>>>>>>> changes here
>>>>>>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>>>>>>> exception,
>>>>>>>>>> it
>>>>>>>>>> seems to me that that will never come (it is rethrown as
>>>>>>>>>> invalidurl
>>>>>>>>>> in
>>>>>>>>>> 1)
>>>>>>>>>>
>>>>>>>>>> Do I miss something here ?
>>>>>>>>>> If not, I would say that the UnAuthorizedExceptions should be
>>>>>>>>>> rethrown
>>>>>>>>>> as
>>>>>>>>>> such at the WebRequestCycleProcessor.
>>>>>>>>>>
>>>>>>>>>> Kind Regards,
>>>>>>>>>>
>>>>>>>>>> Olger
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24677165.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
--
View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24678283.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException -> how to deal with it ?
Posted by Olger Warnier <ol...@xs4all.nl>.
Sorry to keep on buggin over this, I try to understand what is the
best option to plugin the unauthorized type of exceptions into the
wicket framework.
It seems (maybe because of lack of understanding) that the
UnAuthorizedException handling can't work as it is now.
Now to move on:
I've read the RFE Alex sent.
As you create a more specific extension of the runtime exception, it
will be wrapped by the WebRequestCycleProcessor to an
InvalidURLException.
How do you make sure that it will show the 404 ? (or is that default
for the InvalidURLException ?)
It might be an idea to have some kind of exception resolvement at the
spot where this decision is made. (I don't know where that is, I have
seen hints that this is already done somehow and you are able to
override it. ) and throw runtime exceptions as is to that level. By
registering exception handler pages you have the option to customize
the behaviour.
If I like to do that in the current situation, I need to handle the
InvalidUrlException, check the cause and do something only in the case
I'd like to process (Unauthorized)
What to do with the other causes of the InvalidUrl then ?
Kind Regards,
Olger
On 27 jul 2009, at 11:41, Alex Objelean wrote:
>
>
> This is the link of the RFE:
> https://issues.apache.org/jira/browse/WICKET-2307
>
>
> Olger Warnier-2 wrote:
>>
>> On 26 jul 2009, at 22:59, Alex Objelean wrote:
>>>
>>> If you think this would help, then you could remove
>>> InvalidUrlException and
>>> invalidate the jira RFE created by me... I don't think this would
>>> heart
>>> anyone...
>> Intresting, I assume that it is of value to have this construction,
>> could you give me the link to the RFE ?
>>
>> At any time, somehing was a WicketRuntimeException and only a
>> PageExpired (original or as cause) is now rethrown. All others are
>> wrapped.
>> Is there a case that in the AbstractRequestCycleProcessor the
>> following works then ?
>>
>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>> {
>>>>>>>>> // are authorization exceptions always
>>>>>>>>> thrown
>>
>> Kind Regards,
>>
>> Olger
>>
>>>
>>> Alex
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> my point is that this case is on the fence.
>>>>
>>>> it is an invalid url, and it is a security violation. so which one
>>>> should take precendence?
>>>>
>>>> my other concern is that we would have to maintain a long list of
>>>> exceptions that should be passed through, which becomes a pita.
>>>>
>>>> -igor
>>>>
>>>> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objelean@yahoo.com
>>>>>
>>>> wrote:
>>>>>
>>>>> I just want to remind the reason why the InvalidUrlException was
>>>>> introduced:
>>>>> to avoid situations when user would tweak somehow the url and get
>>>>> the
>>>>> InternalError Page... I introduced a request for enhancement for
>>>>> InvalidUrlException feature and if there are any problems related
>>>>> to it,
>>>>> you
>>>>> can blame me..:(
>>>>>
>>>>> Alex Objelean
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>>>
>>>>>> then we are getting in a debate of what use an
>>>>>> invalidurlexception
>>>>>> really is. if we forward page expired and a bunch of other
>>>>>> exceptions,
>>>>>> why do we even need an invalidurlexception...
>>>>>>
>>>>>> the point is the user has submitted a form that they should not
>>>>>> have
>>>>>> been able to, it is an invalid url...
>>>>>>
>>>>>> i dont know off the top of my head what the best approach is.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl>
>>>>>> wrote:
>>>>>>> Hi Igor,
>>>>>>>
>>>>>>>> if the form is disabled why is it allowed to be submitted?
>>>>>>>
>>>>>>> In a test you can ;)
>>>>>>> When you know what to submit, it is possible to submit those
>>>>>>> values
>>>>>>> without
>>>>>>> a page, although I can imagine that it is quite hard to achieve
>>>>>>> due to
>>>>>>> the
>>>>>>> way wicket handles form variables and stuff (via the session).
>>>>>>>
>>>>>>> Even with that in mind, I wonder if it is possible to have the
>>>>>>> UnauthorizedException thrown directly (without the
>>>>>>> InvalidUrlException).
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>> Olger
>>>>>>>
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger
>>>>>>>> Warnier<ol...@xs4all.nl>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Developers,
>>>>>>>>>
>>>>>>>>> Slowly but surely I move through the tests of the wicket
>>>>>>>>> security
>>>>>>>>> framework.
>>>>>>>>> In one test, the SecureFormTest, i ran into some strange
>>>>>>>>> behaviour.
>>>>>>>>> It starts with an exception like this:
>>>>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>>>>> Component
>>>>>>>>> [MarkupContainer [Component id = form]] does not permit action
>>>>>>>>> ENABLE
>>>>>>>>>
>>>>>>>>> (note, the test is commented in order to prevent build
>>>>>>>>> failures)
>>>>>>>>>
>>>>>>>>> There is a secureform that has no rights to be filled an
>>>>>>>>> submitted.
>>>>>>>>> Normal
>>>>>>>>> behaviour till now was the return of a login page. In some
>>>>>>>>> cases I
>>>>>>>>> found
>>>>>>>>> the
>>>>>>>>> return of the UnauthorizedActionException - all fine till now.
>>>>>>>>> (running
>>>>>>>>> 1.4-rc7)
>>>>>>>>> In this test though, I there is no redirection to a Login Page
>>>>>>>>> and I
>>>>>>>>> can't
>>>>>>>>> catch the UnauthorizedActionException. This started my quest
>>>>>>>>> into the
>>>>>>>>> originating throws, this happens to be the throw of an
>>>>>>>>> InvalidUrlException
>>>>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>>>>
>>>>>>>>> catch (WicketRuntimeException e)
>>>>>>>>> {
>>>>>>>>> // we need to let page expired exception
>>>>>>>>> sift
>>>>>>>>> through
>>>>>>>>> instead of covering it up
>>>>>>>>>
>>>>>>>>> if (e instanceof PageExpiredException)
>>>>>>>>> {
>>>>>>>>> throw e;
>>>>>>>>> }
>>>>>>>>> else if (e.getCause() instanceof
>>>>>>>>> PageExpiredException)
>>>>>>>>> {
>>>>>>>>> throw e;
>>>>>>>>> }
>>>>>>>>> else
>>>>>>>>> {
>>>>>>>>> throw new InvalidUrlException(e);
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The UnauthorizedActionException is catched here and thereafter
>>>>>>>>> thrown
>>>>>>>>> wrapped in an InvalidUrlException.
>>>>>>>>>
>>>>>>>>> This is not the end of it, the RequestCycle catches this
>>>>>>>>> exception
>>>>>>>>> and
>>>>>>>>> has
>>>>>>>>> some logic for it (line 1337 starting) :
>>>>>>>>>
>>>>>>>>> catch (RuntimeException e)
>>>>>>>>> {
>>>>>>>>> /*
>>>>>>>>> * check if the raised exception wraps
>>>>>>>>> an abort
>>>>>>>>> exception. if so, it is probably wise to
>>>>>>>>> * unwrap and rethrow the abort exception
>>>>>>>>> */
>>>>>>>>> Throwable cause = e.getCause();
>>>>>>>>> while (cause != null)
>>>>>>>>> {
>>>>>>>>> if (cause instanceof
>>>>>>>>> AbortException)
>>>>>>>>> {
>>>>>>>>> throw
>>>>>>>>> ((AbortException)cause);
>>>>>>>>> }
>>>>>>>>> cause = cause.getCause();
>>>>>>>>> }
>>>>>>>>> if (!handlingException)
>>>>>>>>> {
>>>>>>>>> // set step manually to handle
>>>>>>>>> exception
>>>>>>>>> handlingException = true;
>>>>>>>>>
>>>>>>>>> // probably our last chance the
>>>>>>>>> exception
>>>>>>>>> can
>>>>>>>>> be logged.
>>>>>>>>> // Note that a
>>>>>>>>> PageExpiredException
>>>>>>>>> should
>>>>>>>>> not be logged, because
>>>>>>>>> // it's not an internal error
>>>>>>>>> if (!(e instanceof
>>>>>>>>> PageExpiredException))
>>>>>>>>> {
>>>>>>>>> logRuntimeException(e);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // try to play nicely and let the
>>>>>>>>> request
>>>>>>>>> processor handle the
>>>>>>>>> // exception response. If that
>>>>>>>>> doesn't
>>>>>>>>> work,
>>>>>>>>> any runtime exception
>>>>>>>>> // will automatically be bubbled
>>>>>>>>> up
>>>>>>>>> if (processor != null)
>>>>>>>>> {
>>>>>>>>> processor.respond(e,
>>>>>>>>> this);
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> else..........
>>>>>>>>>
>>>>>>>>> The exception runs through the cause loop, ending with a null
>>>>>>>>> cause,
>>>>>>>>> and
>>>>>>>>> continues to be logged and thereafter triggers a
>>>>>>>>> processor.respond(e,this)
>>>>>>>>> based on the InvalidUrlException.
>>>>>>>>>
>>>>>>>>> This one is catched by the AbstractRequestCycleProcessor,
>>>>>>>>> doing the
>>>>>>>>> following (line 116 and on):
>>>>>>>>>
>>>>>>>>> final Application application =
>>>>>>>>> Application.get();
>>>>>>>>> final IExceptionSettings settings =
>>>>>>>>> application.getExceptionSettings();
>>>>>>>>> final Page responsePage =
>>>>>>>>> requestCycle.getResponsePage();
>>>>>>>>>
>>>>>>>>> Page override = onRuntimeException(responsePage,
>>>>>>>>> e);
>>>>>>>>> if (override != null)
>>>>>>>>> {
>>>>>>>>> throw new
>>>>>>>>> RestartResponseException(override);
>>>>>>>>> }
>>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>>> {
>>>>>>>>> // are authorization exceptions always
>>>>>>>>> thrown
>>>>>>>>> before
>>>>>>>>> the real
>>>>>>>>> // render?
>>>>>>>>> // else we need to make a page (see
>>>>>>>>> below) or
>>>>>>>>> set
>>>>>>>>> it
>>>>>>>>> hard to a
>>>>>>>>> // redirect.
>>>>>>>>> Class<? extends Page>
>>>>>>>>> accessDeniedPageClass =
>>>>>>>>> application.getApplicationSettings()
>>>>>>>>> .getAccessDeniedPage();
>>>>>>>>>
>>>>>>>>> throw new
>>>>>>>>> RestartResponseAtInterceptPageException
>>>>>>>>> (accessDeniedPageClass);
>>>>>>>>> }
>>>>>>>>> else if (e instanceof PageExpiredException)
>>>>>>>>> {
>>>>>>>>> Class<? extends Page>
>>>>>>>>> pageExpiredErrorPageClass
>>>>>>>>> =
>>>>>>>>> application.getApplicationSettings()
>>>>>>>>> .getPageExpiredErrorPage();
>>>>>>>>>
>>>>>>>>> As you can see, this class expects a AuthorizationException,
>>>>>>>>> but the
>>>>>>>>> "e"
>>>>>>>>> in
>>>>>>>>> question is an InvalidUrlException with as cause a
>>>>>>>>> UnauthorizedActionException.
>>>>>>>>>
>>>>>>>>> I could fix this in wicket-security by checking the
>>>>>>>>> InvalidUrlExceptions
>>>>>>>>> somehow ( I assume using the onRuntimeException) for this
>>>>>>>>> cause and
>>>>>>>>> redirect
>>>>>>>>> to a unauthorized page, access denied page (or something), but
>>>>>>>>> I'd
>>>>>>>>> like
>>>>>>>>> to
>>>>>>>>> see what the best option is here.
>>>>>>>>>
>>>>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>>>>> WicketRuntimeException
>>>>>>>>> in
>>>>>>>>> all cases, why is that ?
>>>>>>>>> Is it an option to rethrow when there is a unauthorized type
>>>>>>>>> of
>>>>>>>>> exception
>>>>>>>>> here ?
>>>>>>>>> 2) RequestCycle is doing nothing specific for this matter,
>>>>>>>>> so I
>>>>>>>>> expect
>>>>>>>>> no
>>>>>>>>> changes here
>>>>>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>>>>>> exception,
>>>>>>>>> it
>>>>>>>>> seems to me that that will never come (it is rethrown as
>>>>>>>>> invalidurl
>>>>>>>>> in
>>>>>>>>> 1)
>>>>>>>>>
>>>>>>>>> Do I miss something here ?
>>>>>>>>> If not, I would say that the UnAuthorizedExceptions should be
>>>>>>>>> rethrown
>>>>>>>>> as
>>>>>>>>> such at the WebRequestCycleProcessor.
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>>
>>>>>>>>> Olger
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24677165.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Alex Objelean <al...@yahoo.com>.
This is the link of the RFE:
https://issues.apache.org/jira/browse/WICKET-2307
Olger Warnier-2 wrote:
>
> On 26 jul 2009, at 22:59, Alex Objelean wrote:
>>
>> If you think this would help, then you could remove
>> InvalidUrlException and
>> invalidate the jira RFE created by me... I don't think this would
>> heart
>> anyone...
> Intresting, I assume that it is of value to have this construction,
> could you give me the link to the RFE ?
>
> At any time, somehing was a WicketRuntimeException and only a
> PageExpired (original or as cause) is now rethrown. All others are
> wrapped.
> Is there a case that in the AbstractRequestCycleProcessor the
> following works then ?
>
>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>> {
>>>>>>>> // are authorization exceptions always
>>>>>>>> thrown
>
> Kind Regards,
>
> Olger
>
>>
>> Alex
>>
>>
>> igor.vaynberg wrote:
>>>
>>> my point is that this case is on the fence.
>>>
>>> it is an invalid url, and it is a security violation. so which one
>>> should take precendence?
>>>
>>> my other concern is that we would have to maintain a long list of
>>> exceptions that should be passed through, which becomes a pita.
>>>
>>> -igor
>>>
>>> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objelean@yahoo.com
>>> >
>>> wrote:
>>>>
>>>> I just want to remind the reason why the InvalidUrlException was
>>>> introduced:
>>>> to avoid situations when user would tweak somehow the url and get
>>>> the
>>>> InternalError Page... I introduced a request for enhancement for
>>>> InvalidUrlException feature and if there are any problems related
>>>> to it,
>>>> you
>>>> can blame me..:(
>>>>
>>>> Alex Objelean
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> then we are getting in a debate of what use an invalidurlexception
>>>>> really is. if we forward page expired and a bunch of other
>>>>> exceptions,
>>>>> why do we even need an invalidurlexception...
>>>>>
>>>>> the point is the user has submitted a form that they should not
>>>>> have
>>>>> been able to, it is an invalid url...
>>>>>
>>>>> i dont know off the top of my head what the best approach is.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl>
>>>>> wrote:
>>>>>> Hi Igor,
>>>>>>
>>>>>>> if the form is disabled why is it allowed to be submitted?
>>>>>>
>>>>>> In a test you can ;)
>>>>>> When you know what to submit, it is possible to submit those
>>>>>> values
>>>>>> without
>>>>>> a page, although I can imagine that it is quite hard to achieve
>>>>>> due to
>>>>>> the
>>>>>> way wicket handles form variables and stuff (via the session).
>>>>>>
>>>>>> Even with that in mind, I wonder if it is possible to have the
>>>>>> UnauthorizedException thrown directly (without the
>>>>>> InvalidUrlException).
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> Olger
>>>>>>
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Developers,
>>>>>>>>
>>>>>>>> Slowly but surely I move through the tests of the wicket
>>>>>>>> security
>>>>>>>> framework.
>>>>>>>> In one test, the SecureFormTest, i ran into some strange
>>>>>>>> behaviour.
>>>>>>>> It starts with an exception like this:
>>>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>>>> Component
>>>>>>>> [MarkupContainer [Component id = form]] does not permit action
>>>>>>>> ENABLE
>>>>>>>>
>>>>>>>> (note, the test is commented in order to prevent build failures)
>>>>>>>>
>>>>>>>> There is a secureform that has no rights to be filled an
>>>>>>>> submitted.
>>>>>>>> Normal
>>>>>>>> behaviour till now was the return of a login page. In some
>>>>>>>> cases I
>>>>>>>> found
>>>>>>>> the
>>>>>>>> return of the UnauthorizedActionException - all fine till now.
>>>>>>>> (running
>>>>>>>> 1.4-rc7)
>>>>>>>> In this test though, I there is no redirection to a Login Page
>>>>>>>> and I
>>>>>>>> can't
>>>>>>>> catch the UnauthorizedActionException. This started my quest
>>>>>>>> into the
>>>>>>>> originating throws, this happens to be the throw of an
>>>>>>>> InvalidUrlException
>>>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>>>
>>>>>>>> catch (WicketRuntimeException e)
>>>>>>>> {
>>>>>>>> // we need to let page expired exception
>>>>>>>> sift
>>>>>>>> through
>>>>>>>> instead of covering it up
>>>>>>>>
>>>>>>>> if (e instanceof PageExpiredException)
>>>>>>>> {
>>>>>>>> throw e;
>>>>>>>> }
>>>>>>>> else if (e.getCause() instanceof
>>>>>>>> PageExpiredException)
>>>>>>>> {
>>>>>>>> throw e;
>>>>>>>> }
>>>>>>>> else
>>>>>>>> {
>>>>>>>> throw new InvalidUrlException(e);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> The UnauthorizedActionException is catched here and thereafter
>>>>>>>> thrown
>>>>>>>> wrapped in an InvalidUrlException.
>>>>>>>>
>>>>>>>> This is not the end of it, the RequestCycle catches this
>>>>>>>> exception
>>>>>>>> and
>>>>>>>> has
>>>>>>>> some logic for it (line 1337 starting) :
>>>>>>>>
>>>>>>>> catch (RuntimeException e)
>>>>>>>> {
>>>>>>>> /*
>>>>>>>> * check if the raised exception wraps
>>>>>>>> an abort
>>>>>>>> exception. if so, it is probably wise to
>>>>>>>> * unwrap and rethrow the abort exception
>>>>>>>> */
>>>>>>>> Throwable cause = e.getCause();
>>>>>>>> while (cause != null)
>>>>>>>> {
>>>>>>>> if (cause instanceof
>>>>>>>> AbortException)
>>>>>>>> {
>>>>>>>> throw
>>>>>>>> ((AbortException)cause);
>>>>>>>> }
>>>>>>>> cause = cause.getCause();
>>>>>>>> }
>>>>>>>> if (!handlingException)
>>>>>>>> {
>>>>>>>> // set step manually to handle
>>>>>>>> exception
>>>>>>>> handlingException = true;
>>>>>>>>
>>>>>>>> // probably our last chance the
>>>>>>>> exception
>>>>>>>> can
>>>>>>>> be logged.
>>>>>>>> // Note that a
>>>>>>>> PageExpiredException
>>>>>>>> should
>>>>>>>> not be logged, because
>>>>>>>> // it's not an internal error
>>>>>>>> if (!(e instanceof
>>>>>>>> PageExpiredException))
>>>>>>>> {
>>>>>>>> logRuntimeException(e);
>>>>>>>> }
>>>>>>>>
>>>>>>>> // try to play nicely and let the
>>>>>>>> request
>>>>>>>> processor handle the
>>>>>>>> // exception response. If that
>>>>>>>> doesn't
>>>>>>>> work,
>>>>>>>> any runtime exception
>>>>>>>> // will automatically be bubbled
>>>>>>>> up
>>>>>>>> if (processor != null)
>>>>>>>> {
>>>>>>>> processor.respond(e,
>>>>>>>> this);
>>>>>>>> }
>>>>>>>> }
>>>>>>>> else..........
>>>>>>>>
>>>>>>>> The exception runs through the cause loop, ending with a null
>>>>>>>> cause,
>>>>>>>> and
>>>>>>>> continues to be logged and thereafter triggers a
>>>>>>>> processor.respond(e,this)
>>>>>>>> based on the InvalidUrlException.
>>>>>>>>
>>>>>>>> This one is catched by the AbstractRequestCycleProcessor,
>>>>>>>> doing the
>>>>>>>> following (line 116 and on):
>>>>>>>>
>>>>>>>> final Application application = Application.get();
>>>>>>>> final IExceptionSettings settings =
>>>>>>>> application.getExceptionSettings();
>>>>>>>> final Page responsePage =
>>>>>>>> requestCycle.getResponsePage();
>>>>>>>>
>>>>>>>> Page override = onRuntimeException(responsePage,
>>>>>>>> e);
>>>>>>>> if (override != null)
>>>>>>>> {
>>>>>>>> throw new
>>>>>>>> RestartResponseException(override);
>>>>>>>> }
>>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>>> {
>>>>>>>> // are authorization exceptions always
>>>>>>>> thrown
>>>>>>>> before
>>>>>>>> the real
>>>>>>>> // render?
>>>>>>>> // else we need to make a page (see
>>>>>>>> below) or
>>>>>>>> set
>>>>>>>> it
>>>>>>>> hard to a
>>>>>>>> // redirect.
>>>>>>>> Class<? extends Page>
>>>>>>>> accessDeniedPageClass =
>>>>>>>> application.getApplicationSettings()
>>>>>>>> .getAccessDeniedPage();
>>>>>>>>
>>>>>>>> throw new
>>>>>>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>>>>>>> }
>>>>>>>> else if (e instanceof PageExpiredException)
>>>>>>>> {
>>>>>>>> Class<? extends Page>
>>>>>>>> pageExpiredErrorPageClass
>>>>>>>> =
>>>>>>>> application.getApplicationSettings()
>>>>>>>> .getPageExpiredErrorPage();
>>>>>>>>
>>>>>>>> As you can see, this class expects a AuthorizationException,
>>>>>>>> but the
>>>>>>>> "e"
>>>>>>>> in
>>>>>>>> question is an InvalidUrlException with as cause a
>>>>>>>> UnauthorizedActionException.
>>>>>>>>
>>>>>>>> I could fix this in wicket-security by checking the
>>>>>>>> InvalidUrlExceptions
>>>>>>>> somehow ( I assume using the onRuntimeException) for this
>>>>>>>> cause and
>>>>>>>> redirect
>>>>>>>> to a unauthorized page, access denied page (or something), but
>>>>>>>> I'd
>>>>>>>> like
>>>>>>>> to
>>>>>>>> see what the best option is here.
>>>>>>>>
>>>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>>>> WicketRuntimeException
>>>>>>>> in
>>>>>>>> all cases, why is that ?
>>>>>>>> Is it an option to rethrow when there is a unauthorized type
>>>>>>>> of
>>>>>>>> exception
>>>>>>>> here ?
>>>>>>>> 2) RequestCycle is doing nothing specific for this matter, so I
>>>>>>>> expect
>>>>>>>> no
>>>>>>>> changes here
>>>>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>>>>> exception,
>>>>>>>> it
>>>>>>>> seems to me that that will never come (it is rethrown as
>>>>>>>> invalidurl
>>>>>>>> in
>>>>>>>> 1)
>>>>>>>>
>>>>>>>> Do I miss something here ?
>>>>>>>> If not, I would say that the UnAuthorizedExceptions should be
>>>>>>>> rethrown
>>>>>>>> as
>>>>>>>> such at the WebRequestCycleProcessor.
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>>
>>>>>>>> Olger
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24677165.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Erik van Oosten <e....@grons.nl>.
Sorry Olger,
that was a copy paste error. Please see Alex' e-mail.
Regards,
Erik.
Erik van Oosten schreef:
> Olger Warnier schreef:
>> Intresting, I assume that it is of value to have this construction,
>> could you give me the link to the RFE ?
>
> https://issues.apache.org/jira/browse/WICKET-2200
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Erik van Oosten <e....@grons.nl>.
Olger Warnier schreef:
> Intresting, I assume that it is of value to have this construction,
> could you give me the link to the RFE ?
https://issues.apache.org/jira/browse/WICKET-2200
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException -> how to deal with it ?
Posted by Olger Warnier <ol...@xs4all.nl>.
On 26 jul 2009, at 22:59, Alex Objelean wrote:
>
> If you think this would help, then you could remove
> InvalidUrlException and
> invalidate the jira RFE created by me... I don't think this would
> heart
> anyone...
Intresting, I assume that it is of value to have this construction,
could you give me the link to the RFE ?
At any time, somehing was a WicketRuntimeException and only a
PageExpired (original or as cause) is now rethrown. All others are
wrapped.
Is there a case that in the AbstractRequestCycleProcessor the
following works then ?
>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>> {
>>>>>>> // are authorization exceptions always
>>>>>>> thrown
Kind Regards,
Olger
>
> Alex
>
>
> igor.vaynberg wrote:
>>
>> my point is that this case is on the fence.
>>
>> it is an invalid url, and it is a security violation. so which one
>> should take precendence?
>>
>> my other concern is that we would have to maintain a long list of
>> exceptions that should be passed through, which becomes a pita.
>>
>> -igor
>>
>> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objelean@yahoo.com
>> >
>> wrote:
>>>
>>> I just want to remind the reason why the InvalidUrlException was
>>> introduced:
>>> to avoid situations when user would tweak somehow the url and get
>>> the
>>> InternalError Page... I introduced a request for enhancement for
>>> InvalidUrlException feature and if there are any problems related
>>> to it,
>>> you
>>> can blame me..:(
>>>
>>> Alex Objelean
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> then we are getting in a debate of what use an invalidurlexception
>>>> really is. if we forward page expired and a bunch of other
>>>> exceptions,
>>>> why do we even need an invalidurlexception...
>>>>
>>>> the point is the user has submitted a form that they should not
>>>> have
>>>> been able to, it is an invalid url...
>>>>
>>>> i dont know off the top of my head what the best approach is.
>>>>
>>>> -igor
>>>>
>>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl>
>>>> wrote:
>>>>> Hi Igor,
>>>>>
>>>>>> if the form is disabled why is it allowed to be submitted?
>>>>>
>>>>> In a test you can ;)
>>>>> When you know what to submit, it is possible to submit those
>>>>> values
>>>>> without
>>>>> a page, although I can imagine that it is quite hard to achieve
>>>>> due to
>>>>> the
>>>>> way wicket handles form variables and stuff (via the session).
>>>>>
>>>>> Even with that in mind, I wonder if it is possible to have the
>>>>> UnauthorizedException thrown directly (without the
>>>>> InvalidUrlException).
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Olger
>>>>>
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Developers,
>>>>>>>
>>>>>>> Slowly but surely I move through the tests of the wicket
>>>>>>> security
>>>>>>> framework.
>>>>>>> In one test, the SecureFormTest, i ran into some strange
>>>>>>> behaviour.
>>>>>>> It starts with an exception like this:
>>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>>> Component
>>>>>>> [MarkupContainer [Component id = form]] does not permit action
>>>>>>> ENABLE
>>>>>>>
>>>>>>> (note, the test is commented in order to prevent build failures)
>>>>>>>
>>>>>>> There is a secureform that has no rights to be filled an
>>>>>>> submitted.
>>>>>>> Normal
>>>>>>> behaviour till now was the return of a login page. In some
>>>>>>> cases I
>>>>>>> found
>>>>>>> the
>>>>>>> return of the UnauthorizedActionException - all fine till now.
>>>>>>> (running
>>>>>>> 1.4-rc7)
>>>>>>> In this test though, I there is no redirection to a Login Page
>>>>>>> and I
>>>>>>> can't
>>>>>>> catch the UnauthorizedActionException. This started my quest
>>>>>>> into the
>>>>>>> originating throws, this happens to be the throw of an
>>>>>>> InvalidUrlException
>>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>>
>>>>>>> catch (WicketRuntimeException e)
>>>>>>> {
>>>>>>> // we need to let page expired exception
>>>>>>> sift
>>>>>>> through
>>>>>>> instead of covering it up
>>>>>>>
>>>>>>> if (e instanceof PageExpiredException)
>>>>>>> {
>>>>>>> throw e;
>>>>>>> }
>>>>>>> else if (e.getCause() instanceof
>>>>>>> PageExpiredException)
>>>>>>> {
>>>>>>> throw e;
>>>>>>> }
>>>>>>> else
>>>>>>> {
>>>>>>> throw new InvalidUrlException(e);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> The UnauthorizedActionException is catched here and thereafter
>>>>>>> thrown
>>>>>>> wrapped in an InvalidUrlException.
>>>>>>>
>>>>>>> This is not the end of it, the RequestCycle catches this
>>>>>>> exception
>>>>>>> and
>>>>>>> has
>>>>>>> some logic for it (line 1337 starting) :
>>>>>>>
>>>>>>> catch (RuntimeException e)
>>>>>>> {
>>>>>>> /*
>>>>>>> * check if the raised exception wraps
>>>>>>> an abort
>>>>>>> exception. if so, it is probably wise to
>>>>>>> * unwrap and rethrow the abort exception
>>>>>>> */
>>>>>>> Throwable cause = e.getCause();
>>>>>>> while (cause != null)
>>>>>>> {
>>>>>>> if (cause instanceof
>>>>>>> AbortException)
>>>>>>> {
>>>>>>> throw
>>>>>>> ((AbortException)cause);
>>>>>>> }
>>>>>>> cause = cause.getCause();
>>>>>>> }
>>>>>>> if (!handlingException)
>>>>>>> {
>>>>>>> // set step manually to handle
>>>>>>> exception
>>>>>>> handlingException = true;
>>>>>>>
>>>>>>> // probably our last chance the
>>>>>>> exception
>>>>>>> can
>>>>>>> be logged.
>>>>>>> // Note that a
>>>>>>> PageExpiredException
>>>>>>> should
>>>>>>> not be logged, because
>>>>>>> // it's not an internal error
>>>>>>> if (!(e instanceof
>>>>>>> PageExpiredException))
>>>>>>> {
>>>>>>> logRuntimeException(e);
>>>>>>> }
>>>>>>>
>>>>>>> // try to play nicely and let the
>>>>>>> request
>>>>>>> processor handle the
>>>>>>> // exception response. If that
>>>>>>> doesn't
>>>>>>> work,
>>>>>>> any runtime exception
>>>>>>> // will automatically be bubbled
>>>>>>> up
>>>>>>> if (processor != null)
>>>>>>> {
>>>>>>> processor.respond(e,
>>>>>>> this);
>>>>>>> }
>>>>>>> }
>>>>>>> else..........
>>>>>>>
>>>>>>> The exception runs through the cause loop, ending with a null
>>>>>>> cause,
>>>>>>> and
>>>>>>> continues to be logged and thereafter triggers a
>>>>>>> processor.respond(e,this)
>>>>>>> based on the InvalidUrlException.
>>>>>>>
>>>>>>> This one is catched by the AbstractRequestCycleProcessor,
>>>>>>> doing the
>>>>>>> following (line 116 and on):
>>>>>>>
>>>>>>> final Application application = Application.get();
>>>>>>> final IExceptionSettings settings =
>>>>>>> application.getExceptionSettings();
>>>>>>> final Page responsePage =
>>>>>>> requestCycle.getResponsePage();
>>>>>>>
>>>>>>> Page override = onRuntimeException(responsePage,
>>>>>>> e);
>>>>>>> if (override != null)
>>>>>>> {
>>>>>>> throw new
>>>>>>> RestartResponseException(override);
>>>>>>> }
>>>>>>> else if (e instanceof AuthorizationException)
>>>>>>> {
>>>>>>> // are authorization exceptions always
>>>>>>> thrown
>>>>>>> before
>>>>>>> the real
>>>>>>> // render?
>>>>>>> // else we need to make a page (see
>>>>>>> below) or
>>>>>>> set
>>>>>>> it
>>>>>>> hard to a
>>>>>>> // redirect.
>>>>>>> Class<? extends Page>
>>>>>>> accessDeniedPageClass =
>>>>>>> application.getApplicationSettings()
>>>>>>> .getAccessDeniedPage();
>>>>>>>
>>>>>>> throw new
>>>>>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>>>>>> }
>>>>>>> else if (e instanceof PageExpiredException)
>>>>>>> {
>>>>>>> Class<? extends Page>
>>>>>>> pageExpiredErrorPageClass
>>>>>>> =
>>>>>>> application.getApplicationSettings()
>>>>>>> .getPageExpiredErrorPage();
>>>>>>>
>>>>>>> As you can see, this class expects a AuthorizationException,
>>>>>>> but the
>>>>>>> "e"
>>>>>>> in
>>>>>>> question is an InvalidUrlException with as cause a
>>>>>>> UnauthorizedActionException.
>>>>>>>
>>>>>>> I could fix this in wicket-security by checking the
>>>>>>> InvalidUrlExceptions
>>>>>>> somehow ( I assume using the onRuntimeException) for this
>>>>>>> cause and
>>>>>>> redirect
>>>>>>> to a unauthorized page, access denied page (or something), but
>>>>>>> I'd
>>>>>>> like
>>>>>>> to
>>>>>>> see what the best option is here.
>>>>>>>
>>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>>> WicketRuntimeException
>>>>>>> in
>>>>>>> all cases, why is that ?
>>>>>>> Is it an option to rethrow when there is a unauthorized type
>>>>>>> of
>>>>>>> exception
>>>>>>> here ?
>>>>>>> 2) RequestCycle is doing nothing specific for this matter, so I
>>>>>>> expect
>>>>>>> no
>>>>>>> changes here
>>>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>>>> exception,
>>>>>>> it
>>>>>>> seems to me that that will never come (it is rethrown as
>>>>>>> invalidurl
>>>>>>> in
>>>>>>> 1)
>>>>>>>
>>>>>>> Do I miss something here ?
>>>>>>> If not, I would say that the UnAuthorizedExceptions should be
>>>>>>> rethrown
>>>>>>> as
>>>>>>> such at the WebRequestCycleProcessor.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>> Olger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Alex Objelean <al...@yahoo.com>.
If you think this would help, then you could remove InvalidUrlException and
invalidate the jira RFE created by me... I don't think this would heart
anyone...
Alex
igor.vaynberg wrote:
>
> my point is that this case is on the fence.
>
> it is an invalid url, and it is a security violation. so which one
> should take precendence?
>
> my other concern is that we would have to maintain a long list of
> exceptions that should be passed through, which becomes a pita.
>
> -igor
>
> On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<al...@yahoo.com>
> wrote:
>>
>> I just want to remind the reason why the InvalidUrlException was
>> introduced:
>> to avoid situations when user would tweak somehow the url and get the
>> InternalError Page... I introduced a request for enhancement for
>> InvalidUrlException feature and if there are any problems related to it,
>> you
>> can blame me..:(
>>
>> Alex Objelean
>>
>>
>> igor.vaynberg wrote:
>>>
>>> then we are getting in a debate of what use an invalidurlexception
>>> really is. if we forward page expired and a bunch of other exceptions,
>>> why do we even need an invalidurlexception...
>>>
>>> the point is the user has submitted a form that they should not have
>>> been able to, it is an invalid url...
>>>
>>> i dont know off the top of my head what the best approach is.
>>>
>>> -igor
>>>
>>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl> wrote:
>>>> Hi Igor,
>>>>
>>>>> if the form is disabled why is it allowed to be submitted?
>>>>
>>>> In a test you can ;)
>>>> When you know what to submit, it is possible to submit those values
>>>> without
>>>> a page, although I can imagine that it is quite hard to achieve due to
>>>> the
>>>> way wicket handles form variables and stuff (via the session).
>>>>
>>>> Even with that in mind, I wonder if it is possible to have the
>>>> UnauthorizedException thrown directly (without the
>>>> InvalidUrlException).
>>>>
>>>> Kind Regards,
>>>>
>>>> Olger
>>>>
>>>>>
>>>>> -igor
>>>>>
>>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl>
>>>>> wrote:
>>>>>>
>>>>>> Hi Developers,
>>>>>>
>>>>>> Slowly but surely I move through the tests of the wicket security
>>>>>> framework.
>>>>>> In one test, the SecureFormTest, i ran into some strange behaviour.
>>>>>> It starts with an exception like this:
>>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>>> org.apache.wicket.authorization.UnauthorizedActionException:
>>>>>> Component
>>>>>> [MarkupContainer [Component id = form]] does not permit action ENABLE
>>>>>>
>>>>>> (note, the test is commented in order to prevent build failures)
>>>>>>
>>>>>> There is a secureform that has no rights to be filled an submitted.
>>>>>> Normal
>>>>>> behaviour till now was the return of a login page. In some cases I
>>>>>> found
>>>>>> the
>>>>>> return of the UnauthorizedActionException - all fine till now.
>>>>>> (running
>>>>>> 1.4-rc7)
>>>>>> In this test though, I there is no redirection to a Login Page and I
>>>>>> can't
>>>>>> catch the UnauthorizedActionException. This started my quest into the
>>>>>> originating throws, this happens to be the throw of an
>>>>>> InvalidUrlException
>>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>>
>>>>>> catch (WicketRuntimeException e)
>>>>>> {
>>>>>> // we need to let page expired exception sift
>>>>>> through
>>>>>> instead of covering it up
>>>>>>
>>>>>> if (e instanceof PageExpiredException)
>>>>>> {
>>>>>> throw e;
>>>>>> }
>>>>>> else if (e.getCause() instanceof
>>>>>> PageExpiredException)
>>>>>> {
>>>>>> throw e;
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> throw new InvalidUrlException(e);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The UnauthorizedActionException is catched here and thereafter thrown
>>>>>> wrapped in an InvalidUrlException.
>>>>>>
>>>>>> This is not the end of it, the RequestCycle catches this exception
>>>>>> and
>>>>>> has
>>>>>> some logic for it (line 1337 starting) :
>>>>>>
>>>>>> catch (RuntimeException e)
>>>>>> {
>>>>>> /*
>>>>>> * check if the raised exception wraps an abort
>>>>>> exception. if so, it is probably wise to
>>>>>> * unwrap and rethrow the abort exception
>>>>>> */
>>>>>> Throwable cause = e.getCause();
>>>>>> while (cause != null)
>>>>>> {
>>>>>> if (cause instanceof AbortException)
>>>>>> {
>>>>>> throw ((AbortException)cause);
>>>>>> }
>>>>>> cause = cause.getCause();
>>>>>> }
>>>>>> if (!handlingException)
>>>>>> {
>>>>>> // set step manually to handle
>>>>>> exception
>>>>>> handlingException = true;
>>>>>>
>>>>>> // probably our last chance the
>>>>>> exception
>>>>>> can
>>>>>> be logged.
>>>>>> // Note that a PageExpiredException
>>>>>> should
>>>>>> not be logged, because
>>>>>> // it's not an internal error
>>>>>> if (!(e instanceof
>>>>>> PageExpiredException))
>>>>>> {
>>>>>> logRuntimeException(e);
>>>>>> }
>>>>>>
>>>>>> // try to play nicely and let the
>>>>>> request
>>>>>> processor handle the
>>>>>> // exception response. If that doesn't
>>>>>> work,
>>>>>> any runtime exception
>>>>>> // will automatically be bubbled up
>>>>>> if (processor != null)
>>>>>> {
>>>>>> processor.respond(e, this);
>>>>>> }
>>>>>> }
>>>>>> else..........
>>>>>>
>>>>>> The exception runs through the cause loop, ending with a null cause,
>>>>>> and
>>>>>> continues to be logged and thereafter triggers a
>>>>>> processor.respond(e,this)
>>>>>> based on the InvalidUrlException.
>>>>>>
>>>>>> This one is catched by the AbstractRequestCycleProcessor, doing the
>>>>>> following (line 116 and on):
>>>>>>
>>>>>> final Application application = Application.get();
>>>>>> final IExceptionSettings settings =
>>>>>> application.getExceptionSettings();
>>>>>> final Page responsePage =
>>>>>> requestCycle.getResponsePage();
>>>>>>
>>>>>> Page override = onRuntimeException(responsePage, e);
>>>>>> if (override != null)
>>>>>> {
>>>>>> throw new RestartResponseException(override);
>>>>>> }
>>>>>> else if (e instanceof AuthorizationException)
>>>>>> {
>>>>>> // are authorization exceptions always thrown
>>>>>> before
>>>>>> the real
>>>>>> // render?
>>>>>> // else we need to make a page (see below) or
>>>>>> set
>>>>>> it
>>>>>> hard to a
>>>>>> // redirect.
>>>>>> Class<? extends Page> accessDeniedPageClass =
>>>>>> application.getApplicationSettings()
>>>>>> .getAccessDeniedPage();
>>>>>>
>>>>>> throw new
>>>>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>>>>> }
>>>>>> else if (e instanceof PageExpiredException)
>>>>>> {
>>>>>> Class<? extends Page> pageExpiredErrorPageClass
>>>>>> =
>>>>>> application.getApplicationSettings()
>>>>>> .getPageExpiredErrorPage();
>>>>>>
>>>>>> As you can see, this class expects a AuthorizationException, but the
>>>>>> "e"
>>>>>> in
>>>>>> question is an InvalidUrlException with as cause a
>>>>>> UnauthorizedActionException.
>>>>>>
>>>>>> I could fix this in wicket-security by checking the
>>>>>> InvalidUrlExceptions
>>>>>> somehow ( I assume using the onRuntimeException) for this cause and
>>>>>> redirect
>>>>>> to a unauthorized page, access denied page (or something), but I'd
>>>>>> like
>>>>>> to
>>>>>> see what the best option is here.
>>>>>>
>>>>>> 1) WebRequestCycleProcessor does not rethrow the
>>>>>> WicketRuntimeException
>>>>>> in
>>>>>> all cases, why is that ?
>>>>>> Is it an option to rethrow when there is a unauthorized type of
>>>>>> exception
>>>>>> here ?
>>>>>> 2) RequestCycle is doing nothing specific for this matter, so I
>>>>>> expect
>>>>>> no
>>>>>> changes here
>>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>>> exception,
>>>>>> it
>>>>>> seems to me that that will never come (it is rethrown as invalidurl
>>>>>> in
>>>>>> 1)
>>>>>>
>>>>>> Do I miss something here ?
>>>>>> If not, I would say that the UnAuthorizedExceptions should be
>>>>>> rethrown
>>>>>> as
>>>>>> such at the WebRequestCycleProcessor.
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> Olger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException ->
how to deal with it ?
Posted by Igor Vaynberg <ig...@gmail.com>.
my point is that this case is on the fence.
it is an invalid url, and it is a security violation. so which one
should take precendence?
my other concern is that we would have to maintain a long list of
exceptions that should be passed through, which becomes a pita.
-igor
On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<al...@yahoo.com> wrote:
>
> I just want to remind the reason why the InvalidUrlException was introduced:
> to avoid situations when user would tweak somehow the url and get the
> InternalError Page... I introduced a request for enhancement for
> InvalidUrlException feature and if there are any problems related to it, you
> can blame me..:(
>
> Alex Objelean
>
>
> igor.vaynberg wrote:
>>
>> then we are getting in a debate of what use an invalidurlexception
>> really is. if we forward page expired and a bunch of other exceptions,
>> why do we even need an invalidurlexception...
>>
>> the point is the user has submitted a form that they should not have
>> been able to, it is an invalid url...
>>
>> i dont know off the top of my head what the best approach is.
>>
>> -igor
>>
>> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl> wrote:
>>> Hi Igor,
>>>
>>>> if the form is disabled why is it allowed to be submitted?
>>>
>>> In a test you can ;)
>>> When you know what to submit, it is possible to submit those values
>>> without
>>> a page, although I can imagine that it is quite hard to achieve due to
>>> the
>>> way wicket handles form variables and stuff (via the session).
>>>
>>> Even with that in mind, I wonder if it is possible to have the
>>> UnauthorizedException thrown directly (without the InvalidUrlException).
>>>
>>> Kind Regards,
>>>
>>> Olger
>>>
>>>>
>>>> -igor
>>>>
>>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl> wrote:
>>>>>
>>>>> Hi Developers,
>>>>>
>>>>> Slowly but surely I move through the tests of the wicket security
>>>>> framework.
>>>>> In one test, the SecureFormTest, i ran into some strange behaviour.
>>>>> It starts with an exception like this:
>>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>>> org.apache.wicket.authorization.UnauthorizedActionException: Component
>>>>> [MarkupContainer [Component id = form]] does not permit action ENABLE
>>>>>
>>>>> (note, the test is commented in order to prevent build failures)
>>>>>
>>>>> There is a secureform that has no rights to be filled an submitted.
>>>>> Normal
>>>>> behaviour till now was the return of a login page. In some cases I
>>>>> found
>>>>> the
>>>>> return of the UnauthorizedActionException - all fine till now. (running
>>>>> 1.4-rc7)
>>>>> In this test though, I there is no redirection to a Login Page and I
>>>>> can't
>>>>> catch the UnauthorizedActionException. This started my quest into the
>>>>> originating throws, this happens to be the throw of an
>>>>> InvalidUrlException
>>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>>
>>>>> catch (WicketRuntimeException e)
>>>>> {
>>>>> // we need to let page expired exception sift
>>>>> through
>>>>> instead of covering it up
>>>>>
>>>>> if (e instanceof PageExpiredException)
>>>>> {
>>>>> throw e;
>>>>> }
>>>>> else if (e.getCause() instanceof
>>>>> PageExpiredException)
>>>>> {
>>>>> throw e;
>>>>> }
>>>>> else
>>>>> {
>>>>> throw new InvalidUrlException(e);
>>>>> }
>>>>> }
>>>>>
>>>>> The UnauthorizedActionException is catched here and thereafter thrown
>>>>> wrapped in an InvalidUrlException.
>>>>>
>>>>> This is not the end of it, the RequestCycle catches this exception and
>>>>> has
>>>>> some logic for it (line 1337 starting) :
>>>>>
>>>>> catch (RuntimeException e)
>>>>> {
>>>>> /*
>>>>> * check if the raised exception wraps an abort
>>>>> exception. if so, it is probably wise to
>>>>> * unwrap and rethrow the abort exception
>>>>> */
>>>>> Throwable cause = e.getCause();
>>>>> while (cause != null)
>>>>> {
>>>>> if (cause instanceof AbortException)
>>>>> {
>>>>> throw ((AbortException)cause);
>>>>> }
>>>>> cause = cause.getCause();
>>>>> }
>>>>> if (!handlingException)
>>>>> {
>>>>> // set step manually to handle exception
>>>>> handlingException = true;
>>>>>
>>>>> // probably our last chance the exception
>>>>> can
>>>>> be logged.
>>>>> // Note that a PageExpiredException
>>>>> should
>>>>> not be logged, because
>>>>> // it's not an internal error
>>>>> if (!(e instanceof PageExpiredException))
>>>>> {
>>>>> logRuntimeException(e);
>>>>> }
>>>>>
>>>>> // try to play nicely and let the request
>>>>> processor handle the
>>>>> // exception response. If that doesn't
>>>>> work,
>>>>> any runtime exception
>>>>> // will automatically be bubbled up
>>>>> if (processor != null)
>>>>> {
>>>>> processor.respond(e, this);
>>>>> }
>>>>> }
>>>>> else..........
>>>>>
>>>>> The exception runs through the cause loop, ending with a null cause,
>>>>> and
>>>>> continues to be logged and thereafter triggers a
>>>>> processor.respond(e,this)
>>>>> based on the InvalidUrlException.
>>>>>
>>>>> This one is catched by the AbstractRequestCycleProcessor, doing the
>>>>> following (line 116 and on):
>>>>>
>>>>> final Application application = Application.get();
>>>>> final IExceptionSettings settings =
>>>>> application.getExceptionSettings();
>>>>> final Page responsePage = requestCycle.getResponsePage();
>>>>>
>>>>> Page override = onRuntimeException(responsePage, e);
>>>>> if (override != null)
>>>>> {
>>>>> throw new RestartResponseException(override);
>>>>> }
>>>>> else if (e instanceof AuthorizationException)
>>>>> {
>>>>> // are authorization exceptions always thrown
>>>>> before
>>>>> the real
>>>>> // render?
>>>>> // else we need to make a page (see below) or set
>>>>> it
>>>>> hard to a
>>>>> // redirect.
>>>>> Class<? extends Page> accessDeniedPageClass =
>>>>> application.getApplicationSettings()
>>>>> .getAccessDeniedPage();
>>>>>
>>>>> throw new
>>>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>>>> }
>>>>> else if (e instanceof PageExpiredException)
>>>>> {
>>>>> Class<? extends Page> pageExpiredErrorPageClass =
>>>>> application.getApplicationSettings()
>>>>> .getPageExpiredErrorPage();
>>>>>
>>>>> As you can see, this class expects a AuthorizationException, but the
>>>>> "e"
>>>>> in
>>>>> question is an InvalidUrlException with as cause a
>>>>> UnauthorizedActionException.
>>>>>
>>>>> I could fix this in wicket-security by checking the
>>>>> InvalidUrlExceptions
>>>>> somehow ( I assume using the onRuntimeException) for this cause and
>>>>> redirect
>>>>> to a unauthorized page, access denied page (or something), but I'd like
>>>>> to
>>>>> see what the best option is here.
>>>>>
>>>>> 1) WebRequestCycleProcessor does not rethrow the WicketRuntimeException
>>>>> in
>>>>> all cases, why is that ?
>>>>> Is it an option to rethrow when there is a unauthorized type of
>>>>> exception
>>>>> here ?
>>>>> 2) RequestCycle is doing nothing specific for this matter, so I expect
>>>>> no
>>>>> changes here
>>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>>> exception,
>>>>> it
>>>>> seems to me that that will never come (it is rethrown as invalidurl in
>>>>> 1)
>>>>>
>>>>> Do I miss something here ?
>>>>> If not, I would say that the UnAuthorizedExceptions should be rethrown
>>>>> as
>>>>> such at the WebRequestCycleProcessor.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Olger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException
-> how to deal with it ?
Posted by Alex Objelean <al...@yahoo.com>.
I just want to remind the reason why the InvalidUrlException was introduced:
to avoid situations when user would tweak somehow the url and get the
InternalError Page... I introduced a request for enhancement for
InvalidUrlException feature and if there are any problems related to it, you
can blame me..:(
Alex Objelean
igor.vaynberg wrote:
>
> then we are getting in a debate of what use an invalidurlexception
> really is. if we forward page expired and a bunch of other exceptions,
> why do we even need an invalidurlexception...
>
> the point is the user has submitted a form that they should not have
> been able to, it is an invalid url...
>
> i dont know off the top of my head what the best approach is.
>
> -igor
>
> On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl> wrote:
>> Hi Igor,
>>
>>> if the form is disabled why is it allowed to be submitted?
>>
>> In a test you can ;)
>> When you know what to submit, it is possible to submit those values
>> without
>> a page, although I can imagine that it is quite hard to achieve due to
>> the
>> way wicket handles form variables and stuff (via the session).
>>
>> Even with that in mind, I wonder if it is possible to have the
>> UnauthorizedException thrown directly (without the InvalidUrlException).
>>
>> Kind Regards,
>>
>> Olger
>>
>>>
>>> -igor
>>>
>>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl> wrote:
>>>>
>>>> Hi Developers,
>>>>
>>>> Slowly but surely I move through the tests of the wicket security
>>>> framework.
>>>> In one test, the SecureFormTest, i ran into some strange behaviour.
>>>> It starts with an exception like this:
>>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>>> org.apache.wicket.authorization.UnauthorizedActionException: Component
>>>> [MarkupContainer [Component id = form]] does not permit action ENABLE
>>>>
>>>> (note, the test is commented in order to prevent build failures)
>>>>
>>>> There is a secureform that has no rights to be filled an submitted.
>>>> Normal
>>>> behaviour till now was the return of a login page. In some cases I
>>>> found
>>>> the
>>>> return of the UnauthorizedActionException - all fine till now. (running
>>>> 1.4-rc7)
>>>> In this test though, I there is no redirection to a Login Page and I
>>>> can't
>>>> catch the UnauthorizedActionException. This started my quest into the
>>>> originating throws, this happens to be the throw of an
>>>> InvalidUrlException
>>>> in WebRequestCycleProcessor (line 248 and on)
>>>>
>>>> catch (WicketRuntimeException e)
>>>> {
>>>> // we need to let page expired exception sift
>>>> through
>>>> instead of covering it up
>>>>
>>>> if (e instanceof PageExpiredException)
>>>> {
>>>> throw e;
>>>> }
>>>> else if (e.getCause() instanceof
>>>> PageExpiredException)
>>>> {
>>>> throw e;
>>>> }
>>>> else
>>>> {
>>>> throw new InvalidUrlException(e);
>>>> }
>>>> }
>>>>
>>>> The UnauthorizedActionException is catched here and thereafter thrown
>>>> wrapped in an InvalidUrlException.
>>>>
>>>> This is not the end of it, the RequestCycle catches this exception and
>>>> has
>>>> some logic for it (line 1337 starting) :
>>>>
>>>> catch (RuntimeException e)
>>>> {
>>>> /*
>>>> * check if the raised exception wraps an abort
>>>> exception. if so, it is probably wise to
>>>> * unwrap and rethrow the abort exception
>>>> */
>>>> Throwable cause = e.getCause();
>>>> while (cause != null)
>>>> {
>>>> if (cause instanceof AbortException)
>>>> {
>>>> throw ((AbortException)cause);
>>>> }
>>>> cause = cause.getCause();
>>>> }
>>>> if (!handlingException)
>>>> {
>>>> // set step manually to handle exception
>>>> handlingException = true;
>>>>
>>>> // probably our last chance the exception
>>>> can
>>>> be logged.
>>>> // Note that a PageExpiredException
>>>> should
>>>> not be logged, because
>>>> // it's not an internal error
>>>> if (!(e instanceof PageExpiredException))
>>>> {
>>>> logRuntimeException(e);
>>>> }
>>>>
>>>> // try to play nicely and let the request
>>>> processor handle the
>>>> // exception response. If that doesn't
>>>> work,
>>>> any runtime exception
>>>> // will automatically be bubbled up
>>>> if (processor != null)
>>>> {
>>>> processor.respond(e, this);
>>>> }
>>>> }
>>>> else..........
>>>>
>>>> The exception runs through the cause loop, ending with a null cause,
>>>> and
>>>> continues to be logged and thereafter triggers a
>>>> processor.respond(e,this)
>>>> based on the InvalidUrlException.
>>>>
>>>> This one is catched by the AbstractRequestCycleProcessor, doing the
>>>> following (line 116 and on):
>>>>
>>>> final Application application = Application.get();
>>>> final IExceptionSettings settings =
>>>> application.getExceptionSettings();
>>>> final Page responsePage = requestCycle.getResponsePage();
>>>>
>>>> Page override = onRuntimeException(responsePage, e);
>>>> if (override != null)
>>>> {
>>>> throw new RestartResponseException(override);
>>>> }
>>>> else if (e instanceof AuthorizationException)
>>>> {
>>>> // are authorization exceptions always thrown
>>>> before
>>>> the real
>>>> // render?
>>>> // else we need to make a page (see below) or set
>>>> it
>>>> hard to a
>>>> // redirect.
>>>> Class<? extends Page> accessDeniedPageClass =
>>>> application.getApplicationSettings()
>>>> .getAccessDeniedPage();
>>>>
>>>> throw new
>>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>>> }
>>>> else if (e instanceof PageExpiredException)
>>>> {
>>>> Class<? extends Page> pageExpiredErrorPageClass =
>>>> application.getApplicationSettings()
>>>> .getPageExpiredErrorPage();
>>>>
>>>> As you can see, this class expects a AuthorizationException, but the
>>>> "e"
>>>> in
>>>> question is an InvalidUrlException with as cause a
>>>> UnauthorizedActionException.
>>>>
>>>> I could fix this in wicket-security by checking the
>>>> InvalidUrlExceptions
>>>> somehow ( I assume using the onRuntimeException) for this cause and
>>>> redirect
>>>> to a unauthorized page, access denied page (or something), but I'd like
>>>> to
>>>> see what the best option is here.
>>>>
>>>> 1) WebRequestCycleProcessor does not rethrow the WicketRuntimeException
>>>> in
>>>> all cases, why is that ?
>>>> Is it an option to rethrow when there is a unauthorized type of
>>>> exception
>>>> here ?
>>>> 2) RequestCycle is doing nothing specific for this matter, so I expect
>>>> no
>>>> changes here
>>>> 3) AbstractRequestCycleProcessor checks for the authorization
>>>> exception,
>>>> it
>>>> seems to me that that will never come (it is rethrown as invalidurl in
>>>> 1)
>>>>
>>>> Do I miss something here ?
>>>> If not, I would say that the UnAuthorizedExceptions should be rethrown
>>>> as
>>>> such at the WebRequestCycleProcessor.
>>>>
>>>> Kind Regards,
>>>>
>>>> Olger
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670188.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException ->
how to deal with it ?
Posted by Igor Vaynberg <ig...@gmail.com>.
then we are getting in a debate of what use an invalidurlexception
really is. if we forward page expired and a bunch of other exceptions,
why do we even need an invalidurlexception...
the point is the user has submitted a form that they should not have
been able to, it is an invalid url...
i dont know off the top of my head what the best approach is.
-igor
On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnier<ol...@xs4all.nl> wrote:
> Hi Igor,
>
>> if the form is disabled why is it allowed to be submitted?
>
> In a test you can ;)
> When you know what to submit, it is possible to submit those values without
> a page, although I can imagine that it is quite hard to achieve due to the
> way wicket handles form variables and stuff (via the session).
>
> Even with that in mind, I wonder if it is possible to have the
> UnauthorizedException thrown directly (without the InvalidUrlException).
>
> Kind Regards,
>
> Olger
>
>>
>> -igor
>>
>> On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnier<ol...@xs4all.nl> wrote:
>>>
>>> Hi Developers,
>>>
>>> Slowly but surely I move through the tests of the wicket security
>>> framework.
>>> In one test, the SecureFormTest, i ran into some strange behaviour.
>>> It starts with an exception like this:
>>> org.apache.wicket.protocol.http.request.InvalidUrlException:
>>> org.apache.wicket.authorization.UnauthorizedActionException: Component
>>> [MarkupContainer [Component id = form]] does not permit action ENABLE
>>>
>>> (note, the test is commented in order to prevent build failures)
>>>
>>> There is a secureform that has no rights to be filled an submitted.
>>> Normal
>>> behaviour till now was the return of a login page. In some cases I found
>>> the
>>> return of the UnauthorizedActionException - all fine till now. (running
>>> 1.4-rc7)
>>> In this test though, I there is no redirection to a Login Page and I
>>> can't
>>> catch the UnauthorizedActionException. This started my quest into the
>>> originating throws, this happens to be the throw of an
>>> InvalidUrlException
>>> in WebRequestCycleProcessor (line 248 and on)
>>>
>>> catch (WicketRuntimeException e)
>>> {
>>> // we need to let page expired exception sift
>>> through
>>> instead of covering it up
>>>
>>> if (e instanceof PageExpiredException)
>>> {
>>> throw e;
>>> }
>>> else if (e.getCause() instanceof
>>> PageExpiredException)
>>> {
>>> throw e;
>>> }
>>> else
>>> {
>>> throw new InvalidUrlException(e);
>>> }
>>> }
>>>
>>> The UnauthorizedActionException is catched here and thereafter thrown
>>> wrapped in an InvalidUrlException.
>>>
>>> This is not the end of it, the RequestCycle catches this exception and
>>> has
>>> some logic for it (line 1337 starting) :
>>>
>>> catch (RuntimeException e)
>>> {
>>> /*
>>> * check if the raised exception wraps an abort
>>> exception. if so, it is probably wise to
>>> * unwrap and rethrow the abort exception
>>> */
>>> Throwable cause = e.getCause();
>>> while (cause != null)
>>> {
>>> if (cause instanceof AbortException)
>>> {
>>> throw ((AbortException)cause);
>>> }
>>> cause = cause.getCause();
>>> }
>>> if (!handlingException)
>>> {
>>> // set step manually to handle exception
>>> handlingException = true;
>>>
>>> // probably our last chance the exception
>>> can
>>> be logged.
>>> // Note that a PageExpiredException should
>>> not be logged, because
>>> // it's not an internal error
>>> if (!(e instanceof PageExpiredException))
>>> {
>>> logRuntimeException(e);
>>> }
>>>
>>> // try to play nicely and let the request
>>> processor handle the
>>> // exception response. If that doesn't
>>> work,
>>> any runtime exception
>>> // will automatically be bubbled up
>>> if (processor != null)
>>> {
>>> processor.respond(e, this);
>>> }
>>> }
>>> else..........
>>>
>>> The exception runs through the cause loop, ending with a null cause, and
>>> continues to be logged and thereafter triggers a
>>> processor.respond(e,this)
>>> based on the InvalidUrlException.
>>>
>>> This one is catched by the AbstractRequestCycleProcessor, doing the
>>> following (line 116 and on):
>>>
>>> final Application application = Application.get();
>>> final IExceptionSettings settings =
>>> application.getExceptionSettings();
>>> final Page responsePage = requestCycle.getResponsePage();
>>>
>>> Page override = onRuntimeException(responsePage, e);
>>> if (override != null)
>>> {
>>> throw new RestartResponseException(override);
>>> }
>>> else if (e instanceof AuthorizationException)
>>> {
>>> // are authorization exceptions always thrown
>>> before
>>> the real
>>> // render?
>>> // else we need to make a page (see below) or set
>>> it
>>> hard to a
>>> // redirect.
>>> Class<? extends Page> accessDeniedPageClass =
>>> application.getApplicationSettings()
>>> .getAccessDeniedPage();
>>>
>>> throw new
>>> RestartResponseAtInterceptPageException(accessDeniedPageClass);
>>> }
>>> else if (e instanceof PageExpiredException)
>>> {
>>> Class<? extends Page> pageExpiredErrorPageClass =
>>> application.getApplicationSettings()
>>> .getPageExpiredErrorPage();
>>>
>>> As you can see, this class expects a AuthorizationException, but the "e"
>>> in
>>> question is an InvalidUrlException with as cause a
>>> UnauthorizedActionException.
>>>
>>> I could fix this in wicket-security by checking the InvalidUrlExceptions
>>> somehow ( I assume using the onRuntimeException) for this cause and
>>> redirect
>>> to a unauthorized page, access denied page (or something), but I'd like
>>> to
>>> see what the best option is here.
>>>
>>> 1) WebRequestCycleProcessor does not rethrow the WicketRuntimeException
>>> in
>>> all cases, why is that ?
>>> Is it an option to rethrow when there is a unauthorized type of
>>> exception
>>> here ?
>>> 2) RequestCycle is doing nothing specific for this matter, so I expect no
>>> changes here
>>> 3) AbstractRequestCycleProcessor checks for the authorization exception,
>>> it
>>> seems to me that that will never come (it is rethrown as invalidurl in 1)
>>>
>>> Do I miss something here ?
>>> If not, I would say that the UnAuthorizedExceptions should be rethrown as
>>> such at the WebRequestCycleProcessor.
>>>
>>> Kind Regards,
>>>
>>> Olger
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org