Well, I'll add that to the WaspWebApplication and check if that will do.
Thanks.

I'll check
On 27 jul 2009, at 12:37, Alex Objelean wrote:



You can treat runtime exceptions by overriding newRequestCycle method of
your Application class...
@Override
public Page onRuntimeException(final Page page, final RuntimeException e)
{
    if (e instanceof InvalidUrlException) {
      //redirect to 404
    } else {
       return super.onRuntimeException(page, e);
    }
 }


Olger Warnier-2 wrote:

Sorry to keep on buggin over this, I try to understand what is the
best option to plugin the unauthorized type of exceptions into the
wicket framework.
It seems (maybe because of lack of understanding) that the
UnAuthorizedException handling can't work as it is now.
Now to move on:

I've read the RFE Alex sent.

As you create a more specific extension of the runtime exception, it
will be wrapped by the WebRequestCycleProcessor to an
InvalidURLException.

How do you make sure that it will show the 404 ? (or is that default
for the InvalidURLException ?)

It might be an idea to have some kind of exception resolvement at the
spot where this decision is made. (I don't know where that is, I have
seen hints that this is already done somehow and you are able to
override it. ) and throw runtime exceptions as is to that level. By
registering exception handler pages you have the option to customize
the behaviour.

If I like to do that in the current situation, I need to handle the
InvalidUrlException, check the cause and do something only in the case
I'd like to process (Unauthorized)
What to do with the other causes of the InvalidUrl then ?


Kind Regards,

Olger


On 27 jul 2009, at 11:41, Alex Objelean wrote:



This is the link of the RFE:
https://issues.apache.org/jira/browse/WICKET-2307


Olger Warnier-2 wrote:

On 26 jul 2009, at 22:59, Alex Objelean wrote:

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...
Intresting, I assume that it is of value to have this construction,
could you give me the link to the RFE ?

At any time, somehing was a WicketRuntimeException and only a
PageExpired (original or as cause) is now rethrown. All others are
wrapped.
Is there a case that in the AbstractRequestCycleProcessor the
following works then ?

          else if (e instanceof AuthorizationException)
            {
                    // are authorization exceptions always
thrown

Kind Regards,

Olger


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





---------------------------------------------------------------------
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---tp24668942p24677165.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





--
View this message in context: 
http://www.nabble.com/UnauthorizedActionException-wrapped-in-an-InvalidUrlException--%3E-how-to-deal-with-it---tp24668942p24678283.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

Reply via email to