in reply to Re: Form generation and validation
in thread Form generation and validation

A well behaved model on the backend should do its own validation
Yes, I will do the validation in the backend, especially since the web app is going to be a front-end for a fairly fragile C++ executable. (The original design was to glue this executable with some C CGI library; we have since decided to use a real web framework.)
I would still push validation to the model/data layer. It’s the most natural and reusable place for it.
Agreed. What also worries me is the correspondence between <input name="..."> tags in the form layout and the expectations of the model (query_parameters->get("...") in Dancer terms). Is there a way to enforce it, besides form generation and various forms of testing? I can easily imagine a typo squeezing in one of the rarely used parameters. Making it relatively painless to add new parameters would also be nice.
Also, I would never use the input pattern property. It is invisible to the actual user of the constraint so it’s not good UX and it surfaces your code or expectations to hackers and the client side checks can be bypassed with direct requests/POSTs and regular expressions can be exploited maliciously.
Noted. Does it mean that good client-side validation has to be done in JavaScript? I'm only doing client-side validation for the sake of the user ("prevent errors instead of presenting error messages after the error happened"), but I have personal aversion to client-side scripting (which I can overcome if the job needs it). For most fields, I would be okay with the client being able to verify that a field contains a floating-point number, but browsers are not up to it yet.
ALL user supplied data must be escaped. It’s opt in in TT2. So, anything that comes from params, etc, needs something like: [% name | html %]
Thanks for the reminder. I omitted that in the OP for simplicity, since I was typing code from my head, not having any form backend code yet.

Replies are listed 'Best First'.
Re^3: Form generation and validation
by 1nickt (Canon) on Jul 26, 2019 at 21:12 UTC

    You can and should do some validation on the page in the user's browser, but as noted the real bulwark is the backend. On the other hand you can do it very close to the request arrival so your app doesn't really fire up unless needed. Since you are (rightly) concerned about strict param validation and it sounds like a serious app, I would start out right and create an OpenAPI spec for the app defining the routes and the acceptable params. There are plugins for Dancer which will build the whole app from the spec! And then validate the input if desired, etc. There's no reason to wait until the data is received by a route handler to validate it.


    The way forward always starts with a minimal test.
      Thank you for linking me to OpenAPI specifications! This looks like an interesting idea to pursue, especially since I expect to provide some kind of API in addition to the web page in the future.