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-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
