Nota do editor: Esta série foi originalmente publicada em 2006 e atualizada em 2007 e 2008. Desde sua última publicação, os desenvolvedores do CakePHP fizeram alterações no CakePHP, que resultaram nas diversas revisões desta série. Esta revisão foi escrita para o CakePHP V1.2.2.8120.

Esta série "Elabore Web sites rapidamente com o CakePHP" foi elaborada para desenvolvedores de aplicativos PHP que desejam começar a usar o CakePHP para facilitar suas vidas. No final, será possível aprender como instalar e configurar o CakePHP, o básico do design Model-View-Controller (MVC), como validar dados de usuários e usar os helpers no CakePHP, e como colocar um aplicativo em execução rapidamente usando o CakePHP. Pode parecer que há muito para aprender, mas não se preocupe — o CakePHP faz a maior parte do trabalho por você.

Este artigo considera que você já tenha concluído a Parte 1 e a Parte 2, e que você ainda tenha o ambiente de trabalho configurado para estes tutoriais. Se não tiver instalado o CakePHP, será necessário ler as Partes 1 e 2 antes de continuar.

Consideramos que você conheça o PHP, tenha um entendimento básico de design de bases de dados e que fique à vontade durante o trabalho.

Requisitos do sistema:

Antes de começar, você precisa ter um ambiente em que possa trabalhar. O CakePHP tem requisitos de servidor razoavelmente mínimos:

1. Um servidor HTTP que suporte as sessões (e, de preferência, mod_rewrite). Este tutorial foi escrito usando o Apache V2.2.4 com o mod_rewrite habilitado.
2. PHP V4.3.2 ou posterior (incluindo PHP V5). Este tutorial foi escrito usando o PHP V2.3.
3. Um mecanismo de banco de dados suportado. Este tutorial foi escrito usando o MySQL V5.0.4.

Também será preciso um banco de dados pronto para que seu aplicativo possa utilizá-lo. O artigo fornecerá a sintaxe para criar todas as tabelas necessárias no MySQL.

O modo mais simples de executar obter o CakePHP é visitar CakeForge.org e executar o download da última versão estável. Este tutorial foi escrito usando a versão 1.2.812.0. (Também estão disponíveis construções e cópias noturnas direto do Subversion. Os detalhes encontram-se no Manual do CakePHP (consulte Recursos).

Voltar para parte superior

Tor, até agora

Ao final da Parte 2, você teve outra oportunidade de colocar suas habilidades em prática melhorando o Tor. O Bake foi utilizado para gerar visualizações e um controlador para revendedores e, depois verificar se o nome do revendedor era exclusivo, foi utilizado para corrigir um erro nas ACLs dos produtos e alterar a visualização dos produtos para exibir os botões Editar e Excluir apenas para os usuários que podiam utilizá-los. Foi uma longa lista de tarefas. Como você se saiu?

Aplicando o Bake aos revendedores

A aplicação do Bake ao controlador de revendedores e às visualizações deve ter sido bem simples. Em seu diretório webroot/app, o Console do Cake será iniciado.

Para gerar o controlador, você digitaria C no primeiro menu e selecionaria o controlador de revendedores. Para gerar as visualizações, você digitaria V no primeiro menu e selecionaria o controlador de revendedores novamente. Estas etapas foram praticamente idênticas às etapas seguidas para criar o controlador de produtos e as visualizações.

Foi necessário também garantir que os revendedores tivessem títulos exclusivos. Isso é possível adicionando um método beforeValidate ao modelo do Revendedor, como mostra a Lista 1.

                 function beforeValidate() { if
                (!$this->id) { if ($this->findCount(array('Dealer.title' =>
                $this->data['Dealer']['title'])) > 0) {
                $this->invalidate('title_unique'); return false; } } return true; } 

Para esta tarefa, seria necessário modificar a visualização de inclusão para o revendedor, bem semelhante ao que foi realizado para a visualização do registro de usuário, na busca pelo erro title_unique.

Adicionar conserto de erro de produto

Outra de suas tarefas foi consertar um erro no método products add. Como o método foi deixado para o final da Parte 2, qualquer um poderia adicionar um produto, mesmo sem efetuar login. Há muitas maneiras de consertar isso.

Usando as listas de controle de acesso (ACLs), você poderia criar uma ação no controlador de produtos e usá-la para conceder criar acesso para o objeto do pedido de acesso do usuário (ARO) em cada revendedor ACO. Então, você excluiria a ação porque não precisaria mais dela. Em seguida, você poderia modificar a ação dealer add para conceder permissões criar para o revendedor ACO ao ARO do usuário. Finalmente, no método products add, você poderia certificar-se de que o usuário teria as permissões.

Mas, considerando a tarefa em mãos, havia uma maneira bem mais simples, como mostra a Lista 2.

                 function add() {
                $username = $this->Session->read('user'); if ($username) { ... the
                rest of your add function goes here } else {
                $this->redirect(array('controller' => 'users',
                'action'=>'login'), null, true); } } 

Parece familiar? Deveria. É a mesma verificação que você usa para ver se um usuário efetuou login na ação index do usuário. Se o usuário tiver efetuado login, ele é obviamente um usuário. É uma solução um pouco complicada, mas realmente mostra que há mais de uma maneira de identificar um usuário.

ACLs do Revendedor

Na situação atual, as ações do revendedor estão totalmente desprotegidas. Novamente, elas devem ser modificadas para que somente os usuários possam realmente usá-las, mas as ACLs mais restritas podem e devem ser aplicadas, embora a cobertura total disso seja vasta demais para tratarmos aqui. Considere algo assim:

• Qualquer usuário pode adicionar ou visualizar um revendedor.
• Somente o usuário que criou um revendedor pode modificá-lo ou exclui-lo.

Isso pode ser trabalhado em maior detalhe no aplicativo, como:

• Se um usuário criou um revendedor, ele pode adicionar outro usuário à revenda.
• Qualquer usuário em uma distribuição pode modificar qualquer produto criado para a distribuição.

Existem muitas outras maneiras de fazer isso. Experimente algumas. Não tenha medo de sujar as mãos.

Melhorias na visualização de produtos

A última coisa que você precisou fazer foi modificar as visualizações de produtos para que os botões Editar e Excluir só fossem exibidos para os usuários que conseguissem editar ou excluir o produto. Para começar, você deve remover os botões Editar e Excluir da visualização do índice de Produtos. Em vez disso, você poderia checar cada produto quanto aos direitos do usuário e exibir ou ocultar os botões na visualização do índice, mas esta solução pode não funcionar satisfatoriamente para você.

Na ação da visualização de Produtos, você poderia checar se o usuário tem permissão de atualizar ou excluir o produto e estabelecer variáveis que possam ser usadas para exibir ou ocultar os botões na visualização. A ação de visualização para o controlador de Produtos deve ter algo como o código da Lista 3.

                 if
                ($this->Acl->check($this->Session->read('user'),
                $id.'-'.$product['Product']['title'], 'update')) 
                { $this->set('showUpdate',
                TRUE); } else { $this->set('showUpdate', FALSE); } if
                ($this->Acl->check($this->Session->read('user'),
                $id.'-'.$product['Product']['title'], 'delete')) 
                { $this->set('showDelete',
                TRUE); } else { $this->set('showDelete', FALSE); } 

E em products/view.ctp, você precisa de algo como o que temos abaixo.

                 <?php if ($showUpdate) { ?>
                <li><?php echo $html->link(... your edit link code ...
                ); ?> </li> <?php } ?> <?php if
                ($showDelete) { ?> <li><?php echo $html->link(...
                your edit link code ... ); ?> </li> <?php } ?> 

Novamente, não se preocupe se suas soluções forem idênticas a estas. Elas são exemplos, e não dogmas. Mas você deve fazer download do arquivo de códigos para a Parte 3 para que possamos falar a mesma língua.

Voltar para parte superior

Segurança de dados

Ao lidar com um aplicativo da Web, a importância da segurança de dados não pode ser subestimada. Sob o risco de soar como um comercial de seguro de crédito, você precisa estar sempre atento contra os hackers, cracker, script kiddies. ladrões de identidade, emissores de spams, phishers, criminosos e as velhas pessoas maldosas de sempre. Porém, embora esta situação aconteça há anos, a segurança de dados ainda é frequentemente tratada sem seriedade. Por mais que seu aplicativo da Web seja bonito e elegante, a segurança de dados ruim quebrará as pernas de seu aplicativo. Para entender como lidar com dados ruins, você precisa familiarizar-se com alguns problemas básicos que enfrenta.

O que significa proteger seus dados

Apesar das falhas na segurança de dados causarem tantos problemas, o problema total pode ser resumido em cinco palavras: Saiba o que está ganhando. A segurança de dados não significa retirar todo seu HTML — embora você possa querer isso. Também não significa tirar nenhum caractere especial — embora você possa querer isso. O princípio fundamental é que seu aplicativo saiba o que está ganhando.

Isso não é a mesma coisa que saber o que você quer. Também não é o mesmo que saber o que seu aplicativo pediu. E certamente não é o mesmo que aceitar toda e qualquer coisa.

Injeção SQL

A vulnerabilidade a uma injeção SQL ocorre quando um usuário consegue passar o código SQL diretamente para o aplicativo de modo que o código seja executado em uma query. Por exemplo, o usuário vê uma tela de login, na qual são inseridos o nome do usuário e a senha. A variável senha pode ser usada na seguinte query.

 "select * from users where username = '" + $username + "'
                and password = '" + $password + "'" 

Considere o que poderia acontecer se o usuário enviasse a seguinte senha: ' or '1' = '1. A instrução SQL final poderia ser algo assim:

 "select * from users where username = 'wrestler' and
                password = 'secret' or '1' = '1'" 

Não checar os caracteres SQL específicos pode expor seu aplicativo a uma vasta gama de vulnerabilidades. Quando usado apropriadamente, o Cake pode facilitar a proteção de seu aplicativo deste tipo de vulnerabilidade.

Cross-site scripting

Cross-site scripting (XSS) refere-se a uma ampla classificação de vulnerabilidades que se concentram na habilidade de apresentar um código ruim a um usuário ingênuo. Isso geralmente assume o formulário de um JavaScript malicioso, que pode fazer qualquer coisa, desde incomodar o usuário até capturar dados de cookies.

No coração da vulnerabilidade ao XSS, está um aplicativo que filtra os dados de usuários impróprios assim que enviados. Por exemplo, suponha que você esteja construindo um aplicativo com um fórum e não coloque um filtro contra dados de usuários. Qualquer coisa enviada na postagem de um fórum poderá ser exibida. Como um usuário mal-intencionado. suponha que eu envie o seguinte texto em uma postagem de fórum:

<script>alert("EXPLETIVES!!!")</script>

Se o aplicativo permitir este texto, qualquer um que visse minha postagem receberia uma caixa de alerta do JavaScript que gritaria palavrões para eles. Embora não seja particularmente nocivo, certamente não é algo que você gostaria que seu chefe visse.

Este é um exemplo muito simples de uma exploração XSS não nociva. Embora este exemplo seja bastante inofensivo, o XSS é qualquer coisa menos inofensivo. O XSS tem sido usado para roubar senhas, número de cartões de crédito, forjar histórias na mídia e muito mais. É importante proteger a si mesmo e seu aplicativo de XSS. O CakePHP pode ajudá-lo a fazer isso.

Falsificação de Pedidos Cross-Site

A Falsificação de Pedidos Cross-Site (CRSF) pode não ser tão popular ou bem-conhecida como o XSS, mas isso não a torna menos perigosa. Para demonstrar, suponha que seu aplicativo incluísse um fórum e que o fórum concedesse ao autor de um encadeamento a permissão para excluir o encadeamento. Você colocou isso no fórum como um botão que só é exibido para o autor, e até verifica se o autor é quem fez o pedido antes de executar a exclusão. Isso pode funcionar colocando-se um nome de campo chamado action com o valor delete e um nome de campo chamado id que contenha uma ID única para o encadeamento. Em uma cadeia de caractere de query, pode parecer como http://localhost/forum.php?action=delete&id=1729.

Agora suponha que postemos uma imagem ou que tenhamos a habilidade de especificar uma imagem como uma assinatura, e forneçamos como a URL dessa imagem a mesma cadeia de caractere de query. Em HTML, isso acabaria com mais ou menos esta aparência:

<img
                src="http://localhost/forum.php?action=delete&id=1729">

Eu mesmo não posso ir diretamente para a URL porque não sou o autor, e o aplicativo sabe disso. Mas se o autor visualizar minha postagem, o navegador tentará carregar a imagem pedindo http://localhost/forum.php?action=deleteid=1729&id=1729, e por que o autor está fazendo o pedido, o encadeamento é excluído.

Esta é uma visão extremamente simples da CSRF e de como ela funciona. O componente Security do CakePHP também pode ajudá-lo a se proteger disso.

Voltar para parte superior

Sanitize

O componente Sanitize é usado quando você quer que os dados se adequem a um certo conjunto de regras. No Cake, todos os dados que chegam passam apropriadamente pelo escape, o que corta os problemas potenciais de Injeção SQL pela raiz. Além disso, o Cake fornece alguns métodos no componente Sanitize que você pode usar para limpar seus dados.

O Sanitize é uma classe do CakePHP para ajudá-lo a gerenciar os problemas de segurança de dados. Diferente do componente ACL discutido na Parte 2, o componente Sanitize é incluído pela adição de uma linha no topo de seu controlador. Por exemplo, se você quer usar o Sanitize em seu controlador de produtos, o topo de seu controlador pode ter a aparência mostrada abaixo.

                
                <?php App::import('Sanitize'); class 
                ProductsController extends AppController
                { ... 

O Sanitize fornece quatro métodos para aplicar níveis variáveis de segurança de dados aos dados enviados por usuários. Cada método cumpre uma finalidade distinta.

O método paranoid do Sanitize

Este é o mais rígido dos métodos disponíveis. O método paranoid removerá uma cadeia de caractere de todos os caracteres que não forem alfanuméricos (a-z, A-Z ou 0-9). O método paranoid aceita a inserção de uma cadeia de caractere e um array opcional ($allowedChars). O array $allowedChars pode ser usado para passar um array de caracteres que também sejam permitidos. Por exemplo, se você quisesse que os dados fossem alfanuméricos,sublinhados e pontos, usaria algo assim:

$clean = Sanitize::paranoid($your_data,
                array('_','.'));

Obs.: O método paranoid removerá todos os espaços, a menos que você passe ' ' (um espaço em branco, entre apóstrofes) como um caractere permitido no array $allowedChars.

Esta abordagem à segurança de dados é conhecida como whitelisting. Em vez de remover os caracteres que você não quer (blacklisting), você está removendo todos os caracteres, exceto os que você explicitamente declarou como aceitáveis. Isso funciona melhor para lidar com partes de dados que precisam seguir regras específicas (como nomes de usuários, endereços de e-mail e senhas), mas uma abordagem whitelisting pode ser usada para praticamente qualquer tipo de dados não binários.

O método html do Sanitize

O método html do Sanitize pode passar dois parâmetros: a cadeia de caractere passando pelo Sanitize e um operador booleano opcional referido como $remove. Se o $remove for definido como verdadeiro, o método html passa a cadeia de caractere para a função PHP strip_tags, que retornará a cadeia de caractere sem quaisquer tags HTML. Por exemplo, strip_tags("<p>Hello</p>", true) retornará o valor Hello.

Se $remove for falso ou não definido, o método html substitui alguns caracteres por entidades HTML:

• & é substituído por &.
• % é substituído por %.
• < é substituído por <.
• > é substituído por >.
• " é substituído por ".
• ' é substituído por '.
• ( é substituído por (.
• ) é substituído por ).
• + é substituído por +.
• - é substituído por -.

O método html usa preg_replace para executar estas substituições.

O método de escape do Sanitize

O método escape aceita uma cadeia de caractere de qualquer tipo e retorna uma versão SQL segura da mesma cadeia de caractere. Por exemplo, Sanitize::addslashes("O'Brien") retornaria uma cadeia de caractere com o valor O\'Brien.

O método de limpeza do Sanitize

O método clean usa uma cadeia de caractere ou um array como entrada e retorna a mesma cadeia de caractere ou array depois dela ser recursivamente "limpa". O processo de limpeza cobre uma ampla gama de problemas potenciais de dados, como o gerenciamento de barras invertidas complicadas, espaços estranhos, HTML, retornos de carro e outros.

Você pode visualizar estes métodos em cake/libs/sanitize.php para ter uma idéia melhor do que está envolvido. No entanto, você nunca deve modificar os arquivos de base do CakePHP. Isso dificultará os upgrades para novas versões e poderá causar um comportamento inesperado.

Voltar para parte superior

Componente Security do CakePHP

Para usar o componente Security CakePHP, adicione-o ao array dos componentes em seu controlador como fez com a ACL.

var $components = array ('Acl', 'Security');

Simplesmente incluindo o componente Security, diversas coisas acontecem automaticamente, mesmo se você não usá-lo para proteger uma ação:

• Com o uso da classe principal Security, uma chave de autenticação é gerada e escrita para a sessão. A chave de autenticação expirará de acordo com as definições em app/config/core.php.
• A chave de autenticação está definida como uma variável de classe em seu controlador.
• Se qualquer visualização gerada pelo controlador usar @form->create() para criar um formulário, um campo de entrada oculto chamado _Token/key será incluído no formulário que contém a chave de autenticação. Quando o formulário for postado, o valor do campo será comparado ao valor da chave de autenticação na sessão para verificar se o envio do formulário é válido. Quando ocorre a validação, uma nova chave de autenticação é gerada e definida para a sessão.

Agora que incluiu o componente Security, você precisa criar o método beforeFilter no controlador usando o componente Security. Este método será executado automaticamente pelo controlador antes de qualquer método chamado pelo usuário. Este é o local em que você geralmente vai querer executar verificações de segurança.

Existem algumas maneiras de usar o que o componente Security está fazendo por você aqui. A primeira é pedir que os formulários usem o método POST. A segunda é pedir uma chave de autenticação válida. Usar as duas juntas cria uma poderosa base de segurança para seu aplicativo.

requirePost

O método requirePost do Security diz ao CakePHP para ignorar qualquer informação enviada para a ação especificada a menos que o POST tenha sido usado. O método requirePost recebe uma lista de ações dentro do controlador que você deseja proteger. Por exemplo, se você quisesse usar requirePost para proteger os métodos delete e add, seu método beforeFilter teria esta aparência:

Ao pedir que uma ação use somente dados de uma postagem de formulário, você elimina a capacidade de alguém falsificar um pedido usando uma cadeia de caractere de query.

requireAuth

O método requireAuth do Security diz ao CakePHP para validar qualquer envio de formulário com a chave de autorização anteriormente mencionada. Esta validação só ocorreria se o formulário fosse enviado através de POST.

Como o método requirePost, requireAuth recebe uma lista de ações dentro do controlador que você deseja proteger. Por exemplo, se você quisesse usar requireAuth para proteger os métodos delete e add, seu método beforeFilter teria esta aparência:

 < function beforeFilter() {
                $this->Security->requireAuth('delete', 'add'); } 

Para usar requireAuth e requirePost, você só especificaria os dois no método beforeFilter.

                
                function beforeFilter() { $this->Security->requireAuth('delete',
                'add'); $this->Security->requirePost('delete', 'add'); } 

Usar requireAuth e requirePost para proteger uma ação é uma combinação poderosa. Mas você pode misturar e combinar os dois se quiser níveis variáveis de proteção para diferentes métodos.

                
                function beforeFilter() { $this->Security->requireAuth('delete');
                $this->Security->requirePost('delete', 'add'); } 

Pedindo que o envio de um formulário contenha uma chave de autorização válida antes do processamento, você dificulta muito a falsificação de um envio de formulário para outro usuário. Usar requireAuth e requirePost juntos é uma ótima maneira de ajudar a travar seu aplicativo.

Uma palavra sobre o armazenamento em cache

Embora haja vantagens óbvias no uso do requireAuth para proteger ações, também existem algumas desvantagens que precisam ser abordadas. A maioria destas desvantagens cai na categoria de "problemas de execução de cache".

A chave de autenticação é gerada novamente cada vez que um formulário é avaliado com requireAuth. Isso significa que se um usuário enviar um formulário com uma chave que já foi usada, o envio do fomrulário será considerado inválido. Existem diversos casos em que isso poderia ocorrer, inclusive, entre outros, o uso de múltiplas janelas de navegação, o uso do botão Voltar para retornar a uma página anterior, o armazenamento em cache do navegador e do proxy e mais. Embora você possa sentir-se tentado a descartar estes problemas como erros de usuário, você precisa resistir à tentação e planejar como gerenciar com elegância as submissões de formulário inválidas.

O que acontece com os envios de formulário inválidos?

Se um pedido é rejeitado por requirePost ou requireAuth, o aplicativo sai e o usuário recebe uma página 404. Para evitar este comportamento, você pode definir a propriedade $blackHoleCallback do componente Security para o nome de uma função dentro do controlador. Por exemplo, se você tivesse uma ação chamada inválida e uma visualização correspondente, você poderia dizer ao componente Security para enviar os pedidos ruins para a ação inválida. Você pode fazer isso adicionando a linha a seguir ao início de seu método beforeFilter: $this->Security->blackHoleCallback='invalid';.

Isso lhe dá algum controle sobre a apresentação no caso em que um usuário consegue enviar um pedido inválido por meios legítimos. Um bom exemplo disso seria um usuário usando o aplicativo, fazendo uma pausa para o almoço e retornando ao aplicativo depois da chave de autenticação já ter expirado.

Voltar para parte superior

Preenchendo os espaços

Agora que você sabe como usar os componentes Sanitize e Security, coloque-os para funcionar no Tor.

Comece executando o Sanitize em tudo. Para os produtos, usuários e revendedores, use o Sanitize em todos os dados enviados. Cabe a você determinar qual método Sanitize é melhor usar. Em seguida, olhe os controladores e suas ações e determine quais precisam ser protegidos usando requireAuth, e quais precisam ser protegidos usando requirePost. Implemente o componente Security e uso-o apropriadamente. Finalmente, crie uma ação para cada controlador chamado inválido e uso o método para informar o usuário que seu envio de formulário foi inválido.

Voltar para parte superior

Resumo

Os componentes Sanitize e Security do CakePHP não são mágicos. Seu uso não quer dizer que você pode esquecer a segurança dos aplicativos. Entretanto, usá-los facilitará muito sua vida em termos do gerenciamento de algumas das tarefas mais comuns relacionadas à segurança. Ao limpar seus dados e ignorar dados inadequadamente enviados, você já deu excelentes primeiros passos para proteger seu aplicativo.

A Parte 4 enfoca principalmente o componente Session do CakePHP, demonstrando três maneiras de salvar os dados da sessão, bem como o componente Request Handler para ajudá-lo a gerenciar múltiplos tipos de pedidos (navegadores móveis, pedidos contendo XML ou HTML, etc.).

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Consulte CakePHP para aprender mais.
  
  
• O CakePHP API foi detalhadamente documentado. Este é o lugar para obter a documentação mais atualizada.
  
  
• Há uma tonelada de informações disponíveis na The Bakery, a comunidade de usuários do CakePHP.
  
  
• CakePHP Data Validation utiliza expressões regulares PHP compatíveis com Perl.
  
  
• Leia o tutorial intitulado "Como usar as expressões regulares em PHP."
  
  
• Quer aprender mais sobre padrões de design? Cheque Design Patterns: Elements of Reusable Object-Oriented Software , também conhecido como o livro da "Gang Of Four" (Gangue dos Quatro).
  
  
• Consulte algumas Fontes para criação de usuários.
  
  
• Consulte Model-View-Controller na Wikipedia.
  
  
• Aqui estão mais algumas fontes úteis para Model-View-Controller.
  
  
• Consulte uma lista de padrões de design de software.
  
  
• Leia mais sobre Padrões de Design.
  
  
• PHP.net é o recurso central dos desenvolvedores de PHP.
  
  
• Consulte a "Lista de leituras recomendadas em PHP."
  
  
• Navegue por todo o conteúdo PHP do developerWorks.
  
  
• Siga o developerWorks no Twitter.
  
  
• Expanda suas habilidades em PHP consultando os recursos de projetos em PHP do IBM developerWorks.
  
  
• Para ouvir entrevistas e discussões interessantes para desenvolvedores de software, consulte os podcasts do developerWorks.
  
  
• Usando um banco de dados com PHP? Consulte Zend Core para IBM, um ambiente de desenvolvimento e produção PHP perfeito, inovador e fácil de instalar que suporta IBM DB2 V9.
  
  
• Mantenha-se atualizado com os eventos e webcasts técnicos do developerWorks.
  
  
• Verifique as próximas conferências, feiras, webcasts e outros Eventos em todo o mundo que sejam de interesse dos desenvolvedores IBM de código aberto.
  
  
• Visite a Zona de código aberto do developerWoks para informações extensivas sobre como fazer, ferramentas e atualizações de projetos que o ajudarão a desenvolver com as tecnologias de código aberto e usá-las com os produtos IBM.
  
  
• Assista e aprenda sobre a IBM e as tecnologias e funções de produtos de código aberto com as demos on demand do developerWorks grátis.
  
  

Obter produtos e tecnologias

• Inove em seu próximo projeto de desenvolvimento em código aberto com o software de avaliação IBM, disponível para download ou em DVD.
  
  
• Faça download das versões de avaliação de produtos IBM ou explore as avaliações on-line no IBM SOA Sandbox e utilize as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.
  
  

Discutir

• Participe dos blogs developerWorks e envolva-se na comunidade do developerWorks.
  
  
• Participe do Fórum PHP developerWorks: Desenvolvendo aplicativos PHP com produtos IBM Information Management (DB2, IDS).
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Requisitos do sistema:
• Tor, até agora
• Segurança de dados
• Sanitize
• Componente Security do CakePHP
• Preenchendo os espaços
• Resumo
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais