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. >From how I understand it, as it stands, in a portlet environment, a whole new 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 > > Craig > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
