Jani Hartikainen has posted his idea for using forms along with models in a Zend Framework application.
Matthew Weier O'Phinney wrote about using Zend_Form with models. His approach puts a form inside a model, which then uses the form to validate itself. While this idea is not bad, I find it being upside down - I think the form should use the model to validate itself, not the other way around.
Jani describes two alternate methods - using a global model to do the checking or a model-based validation class that would inherit the model's functionality through being extended. He describes each option's setup and potential use (no code is included save for a few small examples).
On DevShed today there's a new tutorial looking at a method for protecting your application (your MySQL/PHP application) forms from malicious attacks like SQL injections.
It has been known for a while that if a form is unsecured, malicious code in the form of MySQL injection will be initiated to attack the site. HTML forms such as drop down menus, search box, check boxes are all susceptible entry points of this type of abuse. This article will explain what happens in this kind of attack, and how to prevent it.
DevShed continues their series on using CodeIgniter to make a simple blogging application with this new article. It focuses on the next step in the blog's evolution - making it able to accept user comments.
A decent blog application, however, must provide users with a mechanism that lets them post their comments easily, and the simplest way to do this is via an HTML form. Therefore, in the next few lines, I'll be explaining how to modify the controller class and the comments view file created in the preceding article to incorporate a basic web form that permits users to post comments on a particular blog entry.
They start by reviewing the code and application so far, ensuring we're all on the same page. From there, they add code into the controller to handle the form input and make a view to create the form itself.
Sameer has posted his "easy way" to validate user input coming in over a POST request:
Validating POST data from a form is a common requirement for a developer. If the number of form fields are few than the validation is a small matter. But the case is different when the form contains more than 15 or 20 fields and some of the fields are mandatory. The following code will give you an idea of how to easily validate mandatory fields, whatever the number of fields.
His method prefixes the form fields with a certain string (in his case "c_") and uses that to loop through and act as a hook to check only the form values that were submitted (and nothing else that happens to be in the $_POST array). Any number of checks could be added on to this simple example including type checks, length and validating off of another field - like a password confirm match.
In a recent post to his blog Mike Bernat gives a quick tip on how to change the default value of a data-time input field in a CakePHP application.
Automagically generated date/time input fields normally default to the current date and time. For a couple of reasons, I had to change this to another default value.
His included code shows how to modify the default behavior of the form input field for the date with an array of parameters including the hour, minute and meridian (am/pm) values for the element.
DevShed continues their series focusing on the security of your web application in this fifth part of the series. This time they look at preventing attacks on your app via correct authentication.
You will probably recall from the last article that I mentioned the existence of two methods of authentication and discussed the first one, which is through an HTML form. In this article, the fifth one in an eight-part series, we'll start with the second method of authentication. We'll also discuss how attackers may gain access to your system.
This authentication method uses a simple form to let the user pass in their credentials. Unfortunately, because of its simplicity, this also opens it up to three kinds of attacks - password sniffing, reply attacks and brute force attacks.
Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.
CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!
His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.
In this new tutorial from DevShed, they continue the series looking at developing a simple web application with security being one of its primary goals.
In the last article we started to build our site and then continued to explore the login script. In this article we will continue to explore the script but will also discuss in detail the process of authentication and its security implications. We will eventually look at some of the common attacks that are perpetrated by malicious users.
This fourth part of the series adds the authentication piece to the puzzle - a simple system that does some form validation and checks the input against a MySQL table (users). Full code explanation and example usage is included.
On the symfony blog Fabien Potencier encourages all symfony developers that the security of your application must be taken seriously and that, despite the built-in protection the framework offers, there still could be issues.
The symfony framework has always provided the tools needed by the developers to secure their applications. With the new form framework, we have added an automatic protection against CSRF. Speaking of the form framework, we have also added a lot of security features to protect you against all sort of injections.
He does include an example, though, of a situation where it's not just about protecting from cross-site scripting or attacks. It's about checking user input to ensure it's what it should be. They give the example of a user pushing an "is_admin" value into a form posting where there wasn't one and updating the right column to give them admin rights.
He mentions some work the Rails team has tried to do to prevent this sort of thing automatically, but Fabian points out what the symfony framework already does - prevent any injected fields other than what's in the forms from being submitted and included.
This new tutorial DevShed has posted today talks about planning for your application's security and some handy tips you can use to keep it safe.
In this article we will look at how to start a project while considering its related security issues. We will focus on form validation as well as other topics such as site structures. To demonstrate the topics that we will be discussing, we will create a site that will enable a user to log in, log out, register and manage passwords.
They look at things like the overall structure of the site (including how it lives on the file system) and protecting your application from dangerous user input through forms.
