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

Reply via email to