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