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
