If you think this would help, then you could remove InvalidUrlException and
invalidate the jira RFE created by me... I don't think this would heart
anyone...
Alex
igor.vaynberg wrote:
>
> 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
>
>
>
--
View this message in context:
http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24670421.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
