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 thrownKind Regards, OlgerAlex 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.comwrote: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 invalidurlexceptionreally 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-igorOn 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 newRestartResponseAtInterceptPageException (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 Iexpect 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