On 27.07.2011, at 10:44, Mike Seth wrote: > Hi, > > I've spotted a quirky behaviour and I want to consult with you guys regarding > this. > > AgaviExecutionContainer::createSystemActionForwardContainer() internally > uses createExecutionContainer() with only two arguments. When the request > method to createExecutionContainer() is omitted, the default behaviour is to > create the forward container in the same request method as the original > request. This is a quirk because an user may e.g. submit a form via a POST, > step on an URL or otherwise trigger an action's write method while not > authenticated (I discovered this by coming to the office in the morning and > trying to use a form I've left open on another day, so my session expired); > in such case, the login action's container will be created in write mode as > well, which of course fails as the user never has a chance to submit login > credentials, so the login action returns its error view that has nothing to > do with the action the user tried to perform. > > It makes sense to have createSystemActionForwardContainer() accept an > argument to override the request method, default it to read, and create a > configurable parameter for the security filter how to behave in each case. > > Thoughts?
Very good point. The behavior of AgaviExecutionContainer::createExecutionContainer() to re-use the request method and other information from the current instance is intentional, but the request method in this case should indeed be "read" in my opinion. I think we should treat this as a bug and fix it, at least for Agavi 1.1. Not just for LoginAction, but for all internal forwards. David P.S.: 0.11 doesn't have this behavior as it didn't have per-container request methods.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
