On Fri, 24 Oct 2003, Craig R. McClanahan wrote::-)
<snip />
Welcome to the "Chain Gang" Don! :-)
With a snappy name like that, we should t-shirts printed up :)
I noticed that your implementation of AuthorizeAction does the same thing that the current Struts RequestProcessor does if authorization fails -- sends a "Bad Request" (status 400) message back. One thing we might consider instead is throwing a Struts-defined authentication exception, which would allow the exception handling mechanism to decide what to do instead.
One nice feature of using the chain approach is that the exception handler (o.a.s.c.ExceptionCatcher) can handle exceptions thrown by *anything* that executes after it is installed in the chain, not just exceptions thrown by Actions. This allows us to use exceptions to enable application-defined handling of lots of exceptional events from the framework as well, rather than simply throwing a 400 response. In addition, sending a 400 isn't going to be possible in a portlet world anyway, so we might as well start thinking about what to do instead, and make it consistent in servlets as well.
What do you think?
Good point. I could have it throw an UnauthorizedException which is handled by UnauthorizedExceptionHandler in the servlet-exception chain before ExceptionHandler. This of course would entail creating o.a.s.c.AbstractUnauthorizedExceptionHandler, o.a.s.c.UnauthorizedException, and o.a.s.c.s.UnauthorizedExceptionHandler which kinda seems like a lot of code for one line in the case of a servlet environment.
I agree that we would need the exception class, but why do we need anything other than the standard handler (o.a.s.c.ExceptionCatcher)? It fires off an exception handling chain, and the default handler there already looks at your <exception> settings in struts-config.xml to figure out what to do for any arbitrary exception class. It's up to the app to handle UnauthorizedException however it wants, just like it's up to the app to handle an SQLException (or any other type, for that matter) returned from an Action.
While we're at it, there are a few other places where Struts 1.1 returns an HTTP error; they should be evaluated for being treated the same way in a chain-based request processor.
CraigFrom how I understand it, as it stands, in a portlet environment, a wholenew chain config would have to be used anyways due to most implementing classes depending on servlet apis. Therefore, to handle an unauthorized case for a portlet, the only addition code would be a different AuthorizeAction implementation, which would need to be provided anyways.
That said, I think throwing an exception is the more logical choice, but it does add several more classes with little functional improvement. Of course, this is really a trivial part to the whole chain so whatever you think is best, I'll code it up :)
Don
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
