I agree with the idea of making the filter validating the request for POST by default (default constructor of the attribute, and provide an overload to pass params HttpVerb[] verbsToApplyValidationFor)
I have a filter design question: right now we register filters like this: [Filter(typeof(FilterType))], I think this is great to enable dependency injection in the constructor for the filter implementation (you won't be able to do that with MS MVC because the filter IS the attribute), in our case is it possible to make AntiForgeryValidationFilterAttribute inherits filter (yes it is) but would it be picked up by Monorail reflection? I guess that's something left for experimentation with the source code / tests On Jun 1, 2:53 pm, "c.sokun" <[email protected]> wrote: > Simons, > > I will look into that the problem now is my first thought was to add > the feature without touching existing code as much possible. > > Looking at the ASP.NET MVC we can't just copy it directly into > MonoRail especially I do not like when I had to deal with HttpContext > and had to detach the code from ASP.NET MVC internal engine but that > is another story now when I tried to copy what ASP.NET MVC does I came > up with the following file/class structure > > Castle.MonoRail.Framework > + Attributes > - AntiForgeryValidationFilterAttribute.cs > + Filters > - AntiForgeryValidationFilter.cs > > But I am not sure where AntiForgeryData and > AntiForgeryDataSerialization class would belong? Do we really need > these two class or not? > Because I AntiForgeryValidationFilterAttribute can have the Properties > exactly the same as AntiForgerData, or I miss something important > there. > > Anyway AntiFogeryValidationFilter can apply both Class & Method level; > however strongly support the idea in this > bloghttp://weblogs.asp.net/dixin/archive/2010/05/22/anti-forgery-request-... > the simplest way is to apply the filter to controller level ignore all > action request != POST. > > Thanks, > Sokun > > On Jun 1, 5:39 am, John Simons <[email protected]> wrote: > > > > > Gauthie, > > Action level filters work fine in Monorail actions. What problems are you > > having? > > > Sokun, > > Regarding $FormHelper.ForgeryToken(), I actually don't think we need this. > > You can use the form parameters to configure it and then write a hidden tag > > as part of rendering the form tag. > > Eg. > > $Form.FormTag("%{ controller='myController', action='myAction', > > useAntiForgeryToken='true', antiForgeryTokenSalt='$^DF2x' }") > > and this would output: > > > <form action="/myController/myAction" method="post"> > > <input name="__RequestVerificationToken" type="hidden" > > value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" /> > > > What do u think? > > > Cheers > > John > > > ________________________________ > > From: Gauthier Segay <[email protected]> > > To: Castle Project Development List <[email protected]> > > Sent: Mon, 31 May, 2010 7:58:15 AM > > Subject: Re: Implementing AntiForgeryValidatorFilter > > > Hi Simon and Sokun, > > > > How come you apply the attribute to the Controller? > > > I think we are lacking action level filter, they only work at > > controller level at the moment in monorail > > > > My thoughts on this, try to copy has much from the MS implementation as > > > possible (no point reinventing the wheel). > > > +1, we should even try to leverage the classes that don't interact > > directly with the abstract HttpContext or mvc internals, but > > unfortunately System.Web.Mvc.AntiForgeryData is internal sealed :( > > > > ${XssHiddenField} should be a helper eg. $FormHelper.ForgeryToken() > > > +1, I would name it $FormHelper.ForgeryTokenField or > > $FormHelper.ForgeryTokenHiddenField unless it's just the token value > > to be more explicit > > > On 30 mai, 06:00, "c.sokun" <[email protected]> wrote: > > > > Thanks Simon, > > > > I will adapt MS implementation in a few area like generating and > > > serialize token string into cookie. > > > I also like this idea $FormHelper.ForgeryToken() except that I would > > > have to touch existing code but I add it as and alternative option of $ > > > {XssHiddenField} > > > > Will update you on the progress soon. > > > > Thanks, > > > Sokun > > > > On May 30, 8:18 am, John Simons <[email protected]> wrote: > > > > > Hi Sokun, > > > > > Good specs :) > > > > How come you apply the attribute to the Controller?d > > > > I thought you would apply the attribute to the individual Actions, at > > > > least that is what MS has done in ASP.MVC. > > > > > My thoughts on this, try to copy has much from the MS implementation as > > > > possible (no point reinventing the wheel). > > > > > ${XssHiddenField} should be a helper eg. $FormHelper.ForgeryToken() > > > > > Cheers > > > > John > > > > > ________________________________ > > > > From: c.sokun <[email protected]> > > > > To: Castle Project Development List > > > > <[email protected]> > > > > Sent: Sun, 30 May, 2010 1:31:46 AM > > > > Subject: Implementing AntiForgeryValidatorFilter > > > > > I am current working on AntiForgeryValidatorFilter for MonoRail but > > > > before I start coding I want to have your feedback on the usage and > > > > implementation direction. > > > > > Usage: > > > > 1. At the server side code > > > > > [AntiForgeryValidatorFilter()] > > > > public class HomeController: SmartDispatcherController { > > > > public void Index(){ > > > > > } > > > > > } > > > > > 2. View Template > > > > <form method="POST" action="...."> > > > > ${XssHiddenField} > > > > </form> > > > > > Implementation: > > > > > - The Filter only work for POST > > > > - The Filter will automatically setup AntiForgery Cookie if it doesn't > > > > exist (in encrypted form) > > > > - The Filter will regenerate & store new toke value in Cookie after > > > > successful POST. (not sure if this practical?) > > > > - The Filter will create and store two string value in PropertyBag, > > > > a, XssHiddenField // <input type='hidden' value='tokenString' /> > > > > b, XssTokenString // raw token string which usual for crafting > > > > $.ajax $.post etc > > > > - more configuration features > > > > > I think the usage is quiet simple and easily integrate into existing > > > > app; now the challenge is > > > > - The Filter will automatically setup AntiForgery Cookie if it doesn't > > > > exist (in encrypted form) > > > > - The Filter will regenerate & store new toke value in Cookie after > > > > successful POST. (not sure if this practical?) > > > > am I going into the right direction? > > > > > Thanks, > > > > Sokun > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Castle Project Development List" group. > > > > To post to this group, send email to > > > > [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/castle-project-devel?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Development List" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
