my point is that this case is on the fence.
it is an invalid url, and it is a security violation. so which one
should take precendence?
my other concern is that we would have to maintain a long list of
exceptions that should be passed through, which becomes a pita.
-igor
On Sun, Jul 26, 2009 at 1:32 PM, Alex Objelean<alex_objel...@yahoo.com> wrote:
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
