Implementing AntiForgeryValidatorFilter

[c.sokun]

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

[John Simons]

Hi Sokun,

Good specs :)
How come you apply the attribute to the Controller?
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 <chorn...@gmail.com>
To: Castle Project Development List <castle-pro...@googlegroups.com>
Sent: Sun, 30 May, 2010 1:31:46 AM
Subject: Implementing AntiForgeryValidatorFilter

--
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

 

[c.sokun]

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 <johnsimons...@yahoo.com.au> 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 <chornso...@gmail.com>

> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Gauthier Segay]

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

[John Simons]

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 <gauthie...@gmail.com>

To: Castle Project Development List <castle-pro...@googlegroups.com>

Sent: Mon, 31 May, 2010 7:58:15 AM
Subject: Re: Implementing AntiForgeryValidatorFilter

> > To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.

> > 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 castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.

[c.sokun]

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 blog
http://weblogs.asp.net/dixin/archive/2010/05/22/anti-forgery-request-recipes-for-asp-net-mvc-and-ajax.aspx
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 <johnsimons...@yahoo.com.au> 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 <gauthier.se...@gmail.com>

> > > To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

> > > 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 castle-pro...@googlegroups.com.

> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Gauthier Segay]

Hi John (not Simons sorry!)

My problem with action level filter might be because I've tried to use
them in the past and wasn't able to make them work, I will check soon
on a project where I use filters (at controller level ATM) and get
back if the issue is still there.

Also, this thread is probably what stuck in my mind the idea that
action level filters are not there:

http://groups.google.com/group/castle-project-users/browse_frm/thread/d28d7141edd966aa/b9630da2a038e3d6

I agree with the idea to embed the token hidden field on Form.FormTag

On May 31, 11:39 pm, John Simons <johnsimons...@yahoo.com.au> 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 <gauthier.se...@gmail.com>

> > > To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

> > > 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 castle-pro...@googlegroups.com.

> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Gauthier Segay]

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" <chornso...@gmail.com> 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-...

[John Simons]

Hi Sokun, any updates on this?

On Jun 2, 8:28 pm, Gauthier Segay <gauthier.se...@gmail.com> wrote:
> Hi John (not Simons sorry!)
>
> My problem with action level filter might be because I've tried to use
> them in the past and wasn't able to make them work, I will check soon
> on a project where I use filters (at controller level ATM) and get
> back if the issue is still there.
>
> Also, this thread is probably what stuck in my mind the idea that
> action level filters are not there:
>

> http://groups.google.com/group/castle-project-users/browse_frm/thread...