Codeigniter 2 + Design Pattern + OAuth

Alterando o Modelando de Classes
Foram inseridas as novas classes (em verde) para contemplar o novo requisito de autenticação de usuários do sistema.  Definimos que no sistema uma Pessoa pode ter mais de uma conta de acesso, ou seja, ela vai poder logar no sistema usando seu usuário de sistema ou de outros serviços como twitter, facebook, etc.

Alterando as tabelas do banco

Criar a tabela Accounts para armazenar as propriedades das conta de usuário

CREATE TABLE  `academico_test`.`accounts` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`provider` varchar(100) DEFAULT NULL,
`login` varchar(150) NOT NULL,
`password` varchar(150) NOT NULL,
`oauth_token` varchar(255) DEFAULT NULL,
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1

Incluir o campo person_id em Accounts que é necessário para relacionar  uma conta a uma pessoa

ALTER TABLE `academico_test`.`accounts` ADD COLUMN `person_id` INT  NOT NULL AFTER `id`;

TDD

Começamos com a classe de teste tests/models/AccountTest.php para validar a criação do modelo.




Fixtures

Criar a fixture de dados em tests/fixtures/accounts_fixt.yml

1:
    provider: 'twitter'
    login: 'fabriziocolombo'
    password: ''
    oauth_token: ''
    person_id: 6
    
2:
    provider: 'facebook'
    login: 'fernandamontenegro'
    password: ''
    oauth_token: ''
    person_id: 4

2:
    provider: 'erp'
    login: 'jms'
    password: '123456'
    oauth_token: ''
    person_id: 7   

Implementação 


Implementar a classe de modelo application/models/Account.php

Agora ao rodar os testes eles devem passar

$  phpunit --testdox --color models/AccountTest.php
------------------
Account
 [x] Should success with valid provider
 [x] Should error message with invalid provider

Configurando a biblioteca Twitter no Ci

Baixar a biblioteca para twitter em http://www.haughin.com/code/twitter/ e seguir os para para instalação e configuração.


Serviço de autenticação com o Padrão de Projeto Strategy
Como a aplicação possibilita mais de uma opção de conta de acesso, vamos aplicar um padrão de projeto conhecido como Strategy, que possibilita implementar mais de um tipo de estatégia para uma finalidade de forma flexível.

Criamos um aquivo de teste em tests/models/AuthenticationServiceTest.php para guiar o desenvolvimento da funcionalidade. Observe que a classe real de acesso ao Twitter foi mockada (Mock)  para os testes.  Isso é possível graças a Injeção de Depêndencia (DI) implementada no método construtor da classe AuthenticationService.

A classe application/model/Authentication.php define a interface que as classes que implementarem a autenticação devem respeitar.

A classe application/model/TwitterAuthentication.php implementa as regras para logar com a conta do twitter no sistema

A classe application/model/ErpAuthentication.php implementa as regras para logar com a conta do próprio sistema. Ela deve ser refatorada para prover maior segurança.

E por fim a classe application/model/AuthenticationService.php que vai servir como uma fábrica de objetos para instanciar em tempo de execução os objetos que implementam a autenticação dependendo da necessidade.



Também foi criada uma pequena Domain Specific Language (DSL) para a autenticação com o uso de Method Chaining do Php 5 que possibilita chamadas com a seguinte API.

$current_user = AuthenticationService::register($account)->using('twitter');