ANN: reform - a type-safe form generation and validation library in the spirit of formlets and digestive-functors < 0.2

[Jeremy Shaw]

I am pleased to annouce the release of 'reform'. A full tutorial is
available here:

http://www.happstack.com/docs/crashcourse/Reform.html

Reform is an HTML form generation and validation library. It follows
in the footsteps of formlets and digestive-functors <= 0.2. In fact,
much of the code in reform comes from the digestive-functors-0.2 code
base.

Reform is designed to be usuable with a wide variety of Haskell web
servers and templating libraries. You can find the following packages
on hackage:

* reform - the core library
* reform-happstack - support for using reform with the Happstack server
* reform-blaze - support for creating forms for blaze-html
* reform-hsp - support for creating forms for HSP (another
xml/html template library)

The source code is available via darcs:

darcs get http://patch-tag.com/r/stepcut/reform

The darcs repo also includes proof-of-concept support for 'Heist'.

Reform will feel very familiar to formlets and digestive-functors <=
0.2 users.

The primary motivation behind this library is to provide a supported
alternative to digestive-functors 0.2 for users that prefer 0.2 over
0.3.

The key new feature in reform is the ability to separate the
validation code from the view generation code. This allows library
authors to provide validators (known as Proofs) which the users can
use when constructing their forms. The proof names appear in the
type-signatures. This allows the library author to ensure that the
value returned by a user created form is not merely the correct type,
but has also passed validation.

The reform-happstack package also provides simple and transparent
Cross-Site Request Forgery (CSRF) protection, using the double-submit
method. This method has some weaknesses. For example, I believe it can
be circumvented if your site is vulnerable to cross-site scripting
(XSS) attacks. If you have suggestions on how to improve the CSRF
protection -- please let us know!

I hope to do a full comparison of reform vs digestive-functors 0.3 vs
yesod forms in a few weeks.

- jeremy

[Felipe Almeida Lessa]

On Mon, May 21, 2012 at 7:18 PM, Jeremy Shaw <jer...@n-heptane.com> wrote:
> I hope to do a full comparison of reform vs digestive-functors 0.3 vs
> yesod forms in a few weeks.

That would be awesome! Just sayin' =).

Cheers,

--
Felipe.

[Jasper Van der Jeugt]

Congrats on the release!

I would like to help out with the full comparison since I have some
knowledge and experience on the subject. Because of the different
approach, I think there's definitely room for two libraries.

Cheers,
Jasper

> --
> You received this message because you are subscribed to the Google Groups "HAppS" group.
> To post to this group, send email to ha...@googlegroups.com.
> To unsubscribe from this group, send email to happs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/happs?hl=en.
>

[Jeremy Shaw]

Sounds great!

I have some vague ideas about what the comparison might reveal -- but
I expect to learn quite a bit in the process, and use that to improve
reform. There is definitely room for more than one form validation
library. They all have shortcomings, and I am hoping something even
better will come along some day :)

- jeremy

> _______________________________________________
> Haskell-Cafe mailing list
> Haskel...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

[Andrey Chudnov]

 Apologies for practicing necromancy on this topic, but I thought it was important to comment on this:

The reform-happstack package also provides simple and transparent
Cross-Site Request Forgery (CSRF) protection, using the double-submit
method. This method has some weaknesses. For example, I believe it can
be circumvented if your site is vulnerable to cross-site scripting
(XSS) attacks. If you have suggestions on how to improve the CSRF
protection -- please let us know!

An XSS vulnerability will defeat any CSRF protection. In a nutshell: if a malicious actor is sitting in the browser (the XSS payload) it can mediate all the interactions between the user and the server, so properly authenticating the user won't give you anything -- you can't know if the action is performed by the user or the exploit [1].
Any method involving inclusion of a personalised token in the form, e.g., as a hidden field is good enough. Double submission is one such method.
If you are serious about helping the web app developers prevent XSS vulnerabilities, there is a range of things you can do: from including an output sanitisation function based on entity substitution (similar to Rails' html_escape aka h function) and strongly encouraging the developers to use it for any parametric output to leveraging the Haskell type system to provide static guarantees that the output is safe w.r.t. XSS.

[1] Well, okay, you can -- I've seen at least one online bank do that. But I don't believe that can be achieved solely within a web app framework.

P.S.: By the way, a long time fan here. Great to see the project moving. Hope I can find some time to contribute.