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