Galvão, IT Expert

Intro

Authentication always been one of the main concerns when developing web applications. This is a first post of a series of three (that’s what I’ve initially planned, I may extend it)that tries to shed some light on this subject. Although all examples in this series are presented using PHP and PostgreSQL, you’ll notice that the concepts involved are pretty common to other web technologies as well.

Part 1 – Concepts

I always liked to think before doing something or, in the worst case, think while doing it. Both strategies work for me, although the second one always requires more time re-coding everything =) The important thing here, and this is commonly overlooked in most development environments I’ve watched in almost 15 years working on the web, is to define which are the concepts involved in authenticating a user, how the application (or, at least this part of the application) should flow.

Read more…

[pt-BR]

On the first article of this series, we defined the concepts involved in validating an element of a HTML form and created a coding pattern that we’ll use in the ‘name’ attribute which will carry the information regarding this validation.

Today we’ll see the definition of special form fields and how we’ll adapt our pattern to them.

When working with text-type fields it’s very simple to implement whether the field is required or not: we just test the number of characters of it’s ‘value’ attribute or it’s entire value to see if it’s empty. More on this on the next articles of this series.

Our job start to get complicated when we work with data types that may contain special characters and formatting. In these cases, it’s not enough to worry if the field was filled. Let’s take an example:

In a customer sign up form we have a text type field where the user must type his phone number. Our problem consists in the variety of representations of a phone number. Our hypothetical user could, for an example, type the following variations:

3555-0081
3555.0081
3555 0081
35550081
35.55.00.81

In all of these cases, our well mannered user is informing what we’ve asked – his phone number. When we have to store this data, however, this variety of formatting masks will be a problem to the organization, indexing and readability of these informations.

The solution to our problem begins with the definition of which special fields we’ll need to validate and how we’ll pass these validation informations both to the client side script (JavaScript) as well to the server side (PHP). As we’ve discussed previously, we’ll use four characters of the ‘name’ attribute to achieve this goal.

So we’ll define six different types of special fields which will be validated by our scripts:

Sure, there are dozens of other special fields that we can validate, but as soon you understand those six it will be relatively simple to implement any other kind of validation.

On the next article of this series we’ll finally begin to see some code and define how we’ll implement an automatic formatting mask in our special fields, so it saves both our time as well as the user’s.

See you there!

—

No primeiro artigo desta série, definimos os conceitos envolvidos na validação de um campo presente em um formulário HTML e criamos um padrão à ser utilizado no atributo ‘name’ que carregará a informação referente à esta validação.

Hoje veremos as definições de tipos de campos especiais e como adaptaremos nosso padrão à validação destes.

Quando trabalhamos com campos do tipo texto em um formulário HTML, nos é muito simples implementar a obrigatoriedade do preenchimento deste campo: basta testarmos pelo número de caracteres presentes no atributo ‘value’ deste ou ainda testarmos se o valor deste campo é diferente de vazio. Veremos mais detalhes sobre isso nas próximas partes desta matéria.

A situação começa a se complicar quando trabalhamos com tipos de dados que podem conter caracteres e formatações especiais. Nestes casos, o preenchimento ou não do campo deixa de ser nossa única preocupação. Observe o seguinte exemplo:

Em um formulário de cadastro de clientes, possuo um campo simples do tipo ‘text’ onde o usuário deve digitar seu telefone. Nosso problema consiste na existência de diversas formas de representação de um número telefônico. Nosso usuário hipotético poderia, por exemplo, utilizar as seguintes variações:

3555-0081
3555.0081
3555 0081
35550081
35.55.00.81

Em todos estes casos, nosso bem-intencionado usuário está nos informando o que pedimos – o seu número de telefone. Entretanto, a partir do momento em que precisamos armazenar esta informação, a existência desta variedade de máscaras de formatação certamente representará um obstáculo para a organização, indexação e legibilidade destas informações.

A solução do problema começa por uma definição de que tipos de campos especiais precisaremos validar e como passaremos estas informações para o script client-side (JavaScript) e para o script server-side (PHP). Como publicado na matéria anterior, utilizaremos quatro caracteres do atributo ‘name’ de nosso campo de formulário para alcançarmos este objetivo.

Sendo assim, definiremos seis tipos diferentes de campos especiais com o qual nossos scripts trabalharão:

É claro que existem dezenas de outros campos especiais que podemos validar, mas a partir do momento que estes seis forem compreendidos, será relativamente simples implementar quaisquer outros tipos de validação.

Na próxima parte desta matéria trataremos da questão de como implementar automaticamente uma máscara em nossos campos especias, de forma à garantir o mínimo de trabalho para nosso usuário e para nosso script server-side.

Até lá!

[pt-BR]

This is a series of 5 articles originally published on iMasters that I’m finally publishing here and also translating to english.

The intention of these articles is to suggest a way to validate form input both in the client (with JavaScript) and server (using PHP) side.

In this first part we’ll discuss something that is vital for any software development process, but often overlooked when we deal with this type of application. Before we do anything we must understand some concepts involved in the process of validation.

There are two general types of validation:

• Requirement: It’s a general characteristic that can be applied to any type of form element.
• Speciality: It’s a specific type of validation that is used on specific form elements.

Beyond that we should consider a feature that recently became very popular on the web:

• Interface Manipulation: Defines a formatting standard or mask to be applied on certain form elements.

Once we get aware of that we should then decide in which way our form elements will carry these characteristics. We know that both PHP and JavaScript can access two form element informations: it’s name (the “name” HTML attribute) and it’s value (the “value” attribute).

We also know that change an element’s value would be too complicated, since we’d have to make dozens of routines so the user don’t get the impression that the information he provided is being adultered.

So, we end up with the “name” attribute, on which we will define a coding standard that wil carry all the validation information we need. This will be achieved by using the first eight characters of the element’s name:

• Requirement: We will define if the element is required or not by starting it’s name with a ‘R’ or any other character.
• Speciality: The second character will define if this element must contain only letters, numbers or both.
• Requirement: The next two characters will define the minimum ammount of characters that this element’s value must have to be considered valid.
• Speciality: The next four characters will define the special validation type, which we’ll discuss on the next article of this series.

Finally the rest of the name’s attribute characters will be the element’s label, which we’ll use on our error messages. The following illustration shows the coding standard that we’ll use on the “name” attribute of our form’s elements:

—

Esta é uma série de 5 artigos originalmente publicada no iMasters que eu finalmente estou postando aquie também traduzindo para o inglês.

A intenção destes artigos é sugerir uma forma de validar a entrada de dados por formulário tanto no lado cliente (com JavaScript) como no lado servidor (com PHP).

Nesta primeira parte discutiremos algo que é vital em qualquer processo de desenvolvimento de software, mas que é frequentemente ignorada quando tratamos deste tipo de aplicação. Antes de fazermos qualquer coisa, precisamos entender os conceitos envolvidos no processo de validação.

Existem dois tipos gerais de validação:

• Obrigatoriedade: É uma característica geral que pode ser aplicada à qualquer elemento de um formulário.
• Especialidade: É um tipo de validação específico que é utilizado em elementos também específicos.

Além disso devemos considerar uma feature que recentemente se tornou muito popular na web:

• Manipulação de Interface: Define um padrão ou máscara de formataçãopara ser aplicada em certos elementos de formulário.

A partir do momento em que nos damos conta disto devemos então decidir de que forma nossos elementos de formulário carregarão essas características. Nós sabemos que tanto o PHP quanto o JavaScript têm acesso à duas informações sobre um elemento de um formulário: o seu nome (o atributo HTML “name”) e seu valor (o atributo “value”).

Também sabemos que seria complicado demais modificarmos o valor de um elemento, pois teríamos que fazer dúzias de rotinas para evitar que o usuário tenha a impressão que as informações que ele forneceu estão sendo adulteradas.

O que nos resta então é o atributo “name”, onde definiremos uma padronização de código que carregará todas as informações de validação que precisamos. Isto serpa feito utilizando os oito primeiros caracteres do nome do elemento:

• Obrigatoriedade: Definiremos se um elemento é requerido ou não iniciando o seu nome com um ‘R’ ou qualquer outro caractere.
• Especialidade: O segundo caractere nos dirá se o elemento precisa conter somente letras, números ou ambos.
• Obrigatoriedade: Os próximos dois caracteres definirão a quantidade mínima de caracteres que o valor deste elemento precisa conter para ser considerado válido.
• Especialidade: Os próximos quatro caracteres definirão o tipo especial de validação, que discutiremos no próximo artigo desta série.

Finalmente os caracteres restantes do atributo “name” serão o rótulo do elemento, que usaremos em nossas mensagens de erro. S ilustração seguinte mostra o padrão de código que usaremos no atributo “name” dos elementos do nosso formulário: