Implantação do Back-end

A estrutura do banco de dados foi baseada no modelo BDR, onde cada tabela expressa um modelo e possui sua própria chave primária, podendo, no entanto, se rela- cionar com outras tabelas gerando itens dependentes. Doze modelos foram criados para dar suporte às funcionalidades implementadas. São eles:

∙ Usuários: modelo que gera o objeto Usuário no primeiro acesso à Agora. Um Usuá- rio contém como atributo um username e uma senha, além de informações como o instituto, e-mail institucional e staff (se o usuário faz parte do corpo discente, do- cente ou funcionário), automaticamente preenchidos através de um protocolo LDAP (Lightweight Directory Access Protocol - Protocolo de Acesso aos Diretórios Leves) de validação dos dados pelo Centro de Computação da Unicamp.

∙ Artigos: modelo que cria um objeto Artigo composto por texto e título com o intuito de publicar informações na Ágora. Apenas o administrador pode criá-lo. ∙ Debates: modelo que gera um objeto Debate, uma thread de publicações do usuário

a respeito de uma questão a ser debatida. Os usuários podem fazer comentários e réplicas nos comentários de outros usuários. Os debates são inseridos na Ágora pelo administrador.

∙ E-mails: modelo que cria e envia e-mails, compostos por um assunto e um texto, e utilizado para enviar alguma informação ao e-mail cadastrado pelo usuário. Apenas administradores podem criar estes objetos.

Capítulo 4. Projeto e-Ágora: a Ágora e a Metodologia da Ação Comunicativa 97

∙ Etapas: modelo que cria cinco objetos contendo as informações preliminares (ob- jetivo, como participar, resultados e término) sobre cada etapa de uma consulta da opinião. Este conteúdo é automaticamente gerado ao se criar uma nova consulta. ∙ Meus Espaços: modelo a partir do qual o usuário pode enviar um feedback so-

bre qualquer elementos e processo da Ágora. Apenas o usuário é capaz de enviar informações, ficando a cargo dos administradores ler e fornecer uma resposta à re- quisição.

∙ Projetos: modelo que cria uma consulta da opinião pública. Gerado pelo adminis- trador, este objeto monta um sub-conjunto de tabelas específicas para um projeto. ∙ Propostas: modelo que cria um objeto Proposta, uma tabela para implementação

da técnica de crowdsourcing desenvolvida para validação do conteúdo relevante ex- traído pelo EOP. O administrador determina a criação deste objeto no momento oportuno de uma consulta.

∙ Questões: modelo que gera o objeto Questão, elemento de participação, como uma pergunta dissertativa, uma votação de múltipla ou única escolha ou uma enquete. Os objetos são inseridos pelo administrador e respondidos pelos usuários.

∙ Relatórios: modelo que gera um objeto Relatório, um documento com os resulta- dos de uma pergunta/enquete ou o resultado final da consulta pública. Pode agregar elementos como gráficos de pizza, barras e rosca. Um Relatório é criado pelo admi- nistrador, que decide a etapa da pesquisa em que deseja apresentá-lo.

∙ Respostas: modelo que cria os objetos que armazenam as respostas do usuário às questões. Apenas o usuário pode criá-lo ao responder interagir com um objeto Questão. O administrador pode obter as respostas em formato já adequado para ser processado pelos algoritmos de mineração de textos.

∙ Termos: modelo dependente da classe Usuários, e que gera um objeto Termo que contém a resposta do usuário sobre o aceite ou não do Termo de Consentimento Livre e Esclarecido (TCLE), apresentado no primeiro acesso à Ágora.

Para o gerenciamento do banco de dados, o Django fornece uma completa interface de administração dos modelos com acesso restrito apenas aos administradores cadastrados (superusers). Nesta interface, todos os objetos criados podem ser consultados e a capacidade de modificar, alterar, criar ou excluir um objeto pode ser programada. A Figura 7 mostra a página de Administração da Ágora com os respectivos modelos implementados.

Para o atendimento de parte dos requisitos não-funcionais, algumas soluções foram elaboradas no back-end. Em relação à privacidade, o uso da página de administração

Figura 7 – Página de Administração criada pelo Django para o gerenciamento do banco de dados.

do Django contempla as necessidades abordadas: o administrador, cadastrado como um superuser e protegido por uma senha forte, possui privilégios para alterar elementos do banco de dados quando necessário. O usuário, mesmo que consiga acesso à página de login da Administração, não terá permissão para acessá-la.

Já em relação à segurança, diversas soluções foram implementadas tanto para garantir a segurança do banco de dados, quanto ao acesso e privacidade do usuário. Um ponto sensível da Ágora é a necessidade de autenticação do usuário com suas credenciais de acesso aos serviços acadêmicos da Unicamp (Registro Acadêmico/Funcional e senha). Esta autenticação ocorre através do protocolo LDAP, o qual verifica no banco de dados da universidade se o username e senha fornecidos estão corretos. Uma vez validado, o cadastro do usuário é gerado, ficando armazenados seu Registro Acadêmico/Funcional e a senha para que, em um próximo acesso, não seja necessária uma nova verificação via LDAP.

Duas questões sobre segurança são importantes neste procedimento: a garantia de fluxo seguro da informação privada (senha principalmente) e a garantia de que a senha não será visível aos administradores e nem armazenada “crua” no servidor, de modo a prevenir o sistema contra ataques do tipo man-in-the-midle, mantendo o sigilo sobre a senha. Para o primeiro problema, o acesso a qualquer página da Ágora se dá através

Capítulo 4. Projeto e-Ágora: a Ágora e a Metodologia da Ação Comunicativa 99

do protocolo HTTPS (devidamente certificado), que criptografa a informação que será transmitida, ficando muito menos susceptível a interceptações indesejadas. Em relação ao problema do armazenamento da senha, o Django fornece uma elegante solução utilizando o algoritmo PBKDF2 (KALISKI, 2000), o qual a criptografa a senha e a deixa invisível para qualquer usuário do sistema (mesmo os superusers ). A Figura 8 ilustra um exemplo de cadastro com a senha criptografada. Estas soluções não apenas minimizam problemas com segurança como também criam uma atmosfera adequada para que o usuário se sinta confiante em fornecer seus dados privados.

Figura 8 – Exemplo de um objeto Usuário mostrando a forma de armazenamento da senha. Note que a senha não é armazenada “crua”, mas sim criptografas através do algoritmo PBKDF2.