Development

sfGuardPluginExtraDocumentation/pt_BR

You must first sign up to be able to contribute.

Plugin sfGuard - documentação extra

(tradução para português do original: http://trac.symfony-project.com/wiki/sfGuardPluginExtraDocumentation)

Esta wiki fornece informações adicionais sobre a utilização do sfGuardPlugin para o symfony. É direcionada para iniciantes no symfony. Basicamente, ela extende o arquivo README existente com informação adicional, comentários e algumas correções da versão 1.13 PRE.

Como iniciante no symfony e no sfGuardPlugin, precisei coletar informações de várias fontes para aprender mais sobre o framework e este plugin (especificamente, o livro do symfony e o guia Askeet). Este processo levou algum tempo e foi muito proveitoso. Com este documento procuro ajudar todos, como a atual documentação está correta, porém, curta e assume uma grande quantidade de informação e experiência.

Introdução sobre autorização, segurança e autenticação

A documentação do plugin diz "O sfGuardPlugin adiciona autenticação e autorização acima do padrão do Symfony". Mas o que significa tudo isso?

Basicamente, autenticação e autorização é limitar o acesso para (partes de) sua aplicação. Significa que os usuários deverão logar-se (=autenticação) para obter acesso à determinadas áreas. Diferentes usuários podem ter diferentes 'privilégios' (=autorização). Desta forma, você 'protege' sua aplicação para diferentes tipos de usuários. Igualmente, você pode gerenciar os privilégios no back-end.

Se você ler o Capítulo 6 do livro ('Inside the controller layer', p.100 'Action Security'), terá uma idéia sobre o mecanismo de segurança do symfony. Aqui está um resumo:

O acesso as 'actions' pode ser restringido no symfony. A restrição de acesso às actions é configurado no arquivo myProject/apps/myApplication/modules/myModule/config/security.yml (em itálico é o seu projeto, aplicação e módulo).

Se um usuário solicita uma action que está protegida pelo security.yml, o usuário deve:

  1. estar autenticado (= logado)
  2. possuir as credenciais corretas (= privilégios adequados)

O acesso as partes da aplicação pode ser controlado pelas 'Credentials' no security.yml. Para detalhes, veja a página 103 (credenciais complexas) no livro do symfony.

Nota: nesta documentação, 'usuário' refere-se a pessoa que utiliza a aplicação no frontend. O symfony também possui o objeto sfUser para a manipulação de sessões.

O Gerenciamento de sessões é manipulado pelo objeto sfUser (ou $sf_user nos templates). Este, é um objeto singleton e pode ser acessado de qualquer lugar em sua aplicação. Por exemplo, com $this->getUser()->setAuthenticated(true), que seta o status para logado, e pode ser verificado em seu template com <?php if ($sf_user->isAuthenticated()) ?>.

Você pode adicionar informação específica no objeto sfUser para distinguir entre diferentes tipos de usuários adicionando 'credentials' para o objeto sfUser:

  1. $this->getUser()->setCredential('member') seta o tipo do usuário para 'member'.

O objeto sfUser é um objeto-sessão. Isto significa que sua informação está disponível em toda a sua aplicação até que a sessão termine. Além das credenciais, você pode adicionar informação ao objeto sfUser, que necessitará mais tarde em sua aplicação, adicionando 'atributos', ex. o ID do usuário:

  1. $this->getUser()->setAttribute('member_id', 123, 'membernamespace') armazena 123 para o member_id, que pode ser utilizado posteriormente em sua aplicação com $this->getUser()->getAttribute('member_id'). O 'namespace' é o nome da coleção de atributos e é usado para facilitar a exclusão de todos os atributos relacionados ao mesmo namespace (remoção com $this->getUser()->getAttributeHolder()->removeNamespace('member')).

Então, o que acontece se um usuário pede uma action que está 'protegida' através do security.yml de um módulo?

  1. Se o usuário está autenticado e possui as credenciais corretas, a action é executada
  2. Se o usuário não está identificado/autenticado, a action default de login será executada. A action default de login é definida no 'settings.yml' da sua aplicação! (myProject/apps/myApp/config/settings.yml). O livro do symfony indica o 'security.yml', mas, está incorreto e deveria ser 'setting.yml'.
  3. Se um usuário está identificado mas não possui as credenciais corretas, a action default secure será executada. Está action default secure também é definida no arquivo de configuração 'settings.yml' de sua aplicação.

Ambas as actions default login e secure serão redefinidas para uso com o sfGuardPlugin. Os templates para estas actions também podem ser modificados por você.

Sendo o suficiente sobre as funções de segurança standard do symfony, voltemos ao sfGuardPlugin!

Plugin sfGuard

O plugin sfGuard fornece o modelo (objetos de usuário, grupo e permissão) e os módulos (backend e frontend) para proteger sua aplicação symfony em um minuto por configuração.

Instalação

  • Instalando o plugin

    symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin

Este comando instala o plugin no symfony e no seu projeto em myProject/plugins/sfGuardPlugin.

Examinando-o, você verá que o plugin possui seus próprios diretórios config-, data-, lib- e module-.

sfGuardPlugin adiciona 4 módulos ao seu projeto no diretório '/plugins/sfGuardPlugin/modules':

  1. sfGuardAuth - para a aplicação frontend
  2. sfGuardGroup - para a aplicação backend
  3. sfGuardPermission - para a aplicação backend
  4. sfGuardUser - para a aplicação backend
  • Habilite um ou mais destes módulos no seu settings.yml
    • Para sua aplicação backend você precisa: sfGuardUser, sfGuardGroup, sfGuardPermission
    • Para sua aplicação frontend somente será necessário: sfGuardAuth

Para seu frontend:

    all:
      .settings:
        enabled_modules:      [default, sfGuardAuth]

ou para seu backend

    all:
      .settings:
        enabled_modules:      [default, sfGuardGroup, sfGuardUser, sfGuardPermission]

Plugins instalados não são ativados por default no symfony, então, você terá que ativá-lo por aplicação adicionando ele no 'settings.yml', ex: para frontend ou backend (Você pode setar os plugins ativos por aplicação, podendo ter diferentes plugins por aplicação).

  • Limpe seu cache

    symfony cc

Toda vez que você adicionar classes ou funções, é necessário limpar o cache do symfony

  • Reconstrua seu modelo

    symfony propel-build-all

Agora, o sfGuardPlugin adicionou 7 tabelas ao seu banco de dados! Elas são definidas em '/plugins/sfGuardPlugin/config/schema.xml':

  1. sf_guard_user - A tabela com todos os usuários, contém o nome do usuário, senha etc.
  2. sf_guard_permission - A tabela com todas as permissões, incluindo nome da permissão e descrição
  3. sf_guard_user_permission - A tabela que relaciona 'user' e 'permission' n:m, ex. um usuário pode ter múltiplas permissões e uma permissão pode ser compartilhada com múltiplos usuários.
  4. sf_guard_group - A tabela que define os grupos
  5. sf_guard_user_group - A tabela que lista os usuários de um grupo, um usuário pode fazer parte de múltiplos grupos
  6. sf_guard_group_permission - A tabela que relaciona 'group' e 'permission' n:m
  7. sf_guard_remember - armazena o endereço IP e a remember-key dos usuários

Verifique se as tabelas foram adicionadas em seu banco de dados, se não, um erro ocorreu.

Posteriormente nesta documentação (em Personalizando o modelo sfAuthUser) você poderá ligar sua informação do profile do usuário para a tabela standard 'sf_guard_user'

  • Carregue as fixtures default (=dados do banco de dados para, por ex., testes) (opcional - cria um usuário superadmin)
    symfony propel-load-data myApplication

Fixtures são utilizadas para carregar dados no seu banco de dados. Esta carregerá ambos, o schema.yml existente em sua aplicação e o schema.yml do plugin no seu banco de dados.

  • Opcionalmente habilite o filtro "Remember Me" no filters.yml
    security:
      class: sfGuardBasicSecurityFilter

Protegendo sua aplicação

Para proteger uma aplicação symfony:

  • Ative o módulo sfGuardAuth no settings.yml (myProject/apps/myApp/config/settings.yml) para sua aplicação frontend
    all:
      .settings:
        enabled_modules: [..., sfGuardAuth]

Faça isto removendo o '#' da frente da linha no seu 'settings.yml' default. Melhor ainda, copie as linhas habilitadas acima, todas as linhas sem os '#'; isto lhe proporcionará uma visão limpa das suas configurações ativas (e por alguma razão, somente removendo o '#' da frente das linhas aplicáveis não funcionou em minha aplicação).

  • Altere os módulos default login e secure no settings.yml (myProject/apps/myApp/config/settings.yml), e não no 'security.yml' como descrito na p.101 do livro!
  all:
    .actions:
      login_module:           sfGuardAuth
      login_action:           signin

      secure_module:          sfGuardAuth
      secure_action:          secure

Isto modifica o comportamento default de sua aplicação quando um usuário não está logado ou não possui as credenciais corretas, quando solicitando uma página, como descrito anteriormente na introdução desta wiki.

  • Modifique a classe pai em myUser.class.php da sua aplicação (myProject/apps/myApp/lib/myUser.class.php)
    class myUser extends sfGuardSecurityUser
    {
    }

No padrão do symfony, sem o sfGuardPlugin, myUser é baseado no sfBasicSecurityUser. Com a alteração acima, myUser será baseado no sfGuardSecurityUser. O sfGuardSecurityUser é novamente baseado no sfBasicSecurityUser, então você não perderá nenhuma funcionalidade. O sfGuardSecurityUser extende o sfBasicSecurityUser com métodos como, por ex., signIn e signOut, veja myProject/plugins/sfGuardPlugin/lib/user).

  • Opcionalmente adicione as seguintes regras de routing no routing.yml
    sf_guard_signin:
      url:   /login
      param: { module: sfGuardAuth, action: signin }

    sf_guard_signout:
      url:   /logout
      param: { module: sfGuardAuth, action: signout }

    sf_guard_password:
      url:   /request_password
      param: { module: sfGuardAuth, action: password }

Isto apontará a url .../login para a action 'signin' do módulo 'sfGuardAuth'. Você pode personalizar o parâmetro url de cada route. Isto é opcional porque as regras de routing acima são automaticamente registradas pelo plugin se você habilitar o módulo sfGuardAuth. Entretanto, se você desejar, poderá desabilitar as regras de routing definindo sfGuardPlugin_routes_register para false no arquivo de configuração app.yml.

N.B.: Você deve ter uma regra de routing @homepage (utilizada quando o usuário faz o logout), por exemplo:

    homepage:
      url:   /
      param: { module: member, action: index }
  • Limpe seu cache

    symfony cc

Toda vez que você adicionar classes ou funções, deverá limpar o cache do symfony.

  • Proteja alguns módulos ou toda a sua aplicação no security.yml
    default:
      is_secure: on
  • Está concluído. Agora, se você tentar acessar uma página protegida, será redirecionado para a página de login. Se você carregou as fixtures default, tente fazer o login com o nome de usuário admin e senha admin.

Adicionando seu próprio user-(profile)-model: Personalizando o modelo sfAuthUser

O modelo sfAuthUser, que vem com o plugin, é bem simples. Ele contém:

  • username
  • algorithm
  • salt
  • password
  • created_at
  • last_login
  • is_active
  • is_super_admin

Não existe email, first_name, birthday ou qualquer outras colunas. Entretanto, existe uma forma fácil de adicionar qualquer campo necessário.

Você não deseja alterar o schema.yml do plugin nem a classe 'sfGuardUser' diretamente, porque poderá desejar instalar atualizações do plugin sem ter que adicionar seus campos novamente. Ao invés, você pode adicionar seu próprio profile de usuário em outra classe. Por default, o 'sfGuardUser' procura pela classe de profile de usuário 'sfGuardUserProfile' associada, que você mesmo poderá definir no seu próprio schema.yml.

Aqui está um exemplo simples de uma classe sfGuardUserProfile que você poderá adicionar ao seu próprio schema.yml:

    sf_guard_user_profile:
      _attributes: { phpName: sfGuardUserProfile }
      id:
      user_id:     { type: integer, foreignTable: sf_guard_user, foreignReference: id, required: true, onDelete: cascade }
      first_name:  varchar(20)
      last_name:   varchar(20)
      birthday:    date

user_id é a chave-estrangeira do sf_guard_user. É possível alterar o nome desta chave estrangeira e também a classe de profile do usuario associada no app.yml:

    all:
      sf_guard_plugin:
        profile_class:      sfGuardUserProfile
        profile_field_name: user_id

Você pode agora acessar o profile do usuário através do objeto user:

    $this->getUser()->getGuardUser()->getProfile()->getFirstName()

    // ou via método proxy 
    $this->getUser()->getProfile()->getFirstName()

O método getProfile() retorna o objeto de profile do usuário associado ou cria um novo se nenhum existir.

Quando você deletar um usuário, o profile de usuário associado também é deletado.

Gerenciando seus usuários, permissões e grupos no backend

Para poder gerenciar seus usuários, permissões e grupos, o sfGuardPlugin vem com 3 módulos que podem ser integrados à sua aplicação backend. Estes módulos são auto-gerados graças ao admin-generator do symfony.

  • Ative os módulos no settings.yml
    all:
      .settings:
        enabled_modules: [..., sfGuardGroup, sfGuardPermission, sfGuardUser]
  • Acesse os módulos com o route default:

    http://www.example.com/backend.php/sfGuardUser

Personalizando os templates do módulo sfGuardAuth

Por default, o módulo sfGuardAuth vem com 2 templates bem simples:

  • signinSuccess.php
  • secureSuccess.php

Se você desejar personalizar um destes templates:

  • Crie um módulo sfGuardAuth na sua aplicação
  • Crie um template com o nome do template que você deseja personalizar no seu diretório templates
  • O symfony agora irá utilizar o seu template ao invés do default

Personalizando as ações do módulo sfGuardAuth

Se você deseja personalizar ou adicionar métodos para o sfGuardAuth:

  • Crie um módulo sfGuardAuth em sua aplicação
  • Crie um arquivo actions.class.php em seu diretório actions que herda do BasesfGuardAuthActions
    <?php

    class sfGuardAuthActions extends BasesfGuardAuthActions
    {
      public function executeNewAction()
      {
        return $this->renderText('This is a new sfGuardAuth action.');
      }
    }

Classe sfGuardSecurityUser

Esta classe herda da classe sfBasicSecurityUser do symfony e é utilizada para o objeto user na sua aplicação symfony (porque você configurou no factories.yml anteriormente).

Então, para acessá-la, você pode usar o padrão $this->getUser() nas suas actions ou $sf_user nos seus templates.

sfGuardSecurityUser adiciona alguns métodos:

  • métodos signIn() e signOut()
  • getGuardUser() que retorna o objeto sfGuardUser
  • um grupo de métodos proxy para acessar diretamente o objeto sfGuardUser

Por exemplo, para buscar o nome de usuário atual:

    $this->getUser()->getGuardUser()->getUsername()

    // ou via método proxy 
    $this->getUser()->getUsername()

Flag Super administrator

O sfGuardPlugin tem a noção de super administrator. Um usuário que é um super administrator salta todas as verificações de credenciais.

A flag de super administrator não pode ser setada via web, você deverá setar diretamente no banco de dados ou utilizar a seguinte task do pake:

    symfony promote-super-admin admin

Validadores

O sfGuardPlugin vem com um validador que você poderá utilizar em seus módulos: sfGuardUserValidator.

Este validador é usado pelo módulo sfGuardAuth para validar um usuário e senha, e, automaticamente realizar o signin do usuário.

Verificando a senha do usuário com um método externo

Se você não deseja armazenar a senha no banco de dados porque já possui um servidor LDAP, um arquivo .htaccess ou, se você armazena suas senhas em outra tabela, você poderá fornecer seu próprio callable checkPassword (método estático ou função) no app.yml:

    all:
      sf_guard_plugin:
        check_password_callable: [MyLDAPClass, checkPassword]

Quando o symfony fazer chamada ao método $this->getUser()->checkPassword(), ele chamará seu método ou função. Sua função deverá possuir 2 parâmetros, o primeiro é o nome do usuário e o segundo é a senha. Ela deverá retornar true ou false. Aqui está um template para a função:

    function checkLDAPPassword($username, $password)
    {
      $user = LDAP::getUser($username);
      if ($user->checkPassword($password))
      {
        return true;
      }
      else
      {
        return false;
      }
    }

Modificando o algoritmo utilizado para armazenar senhas

Por default, as senhas são armazenadas com o hash sha1(). Mas, você pode alterar isto com qualquer callable no app.yml:

    all:
      sf_guard_plugin:
        algorithm_callable: [MyCryptoClass, MyCryptoMethod]

ou

    all:
      sf_guard_plugin:
        algorithm_callable: md5

Como o algoritmo é armazendo para cada usuário, você poderá posteriormente alterá-lo sem a necessidade de gerar novamente todas as senhas para os usuários existentes.

Modificando o nome ou período de expiração do cookie "Remember Me"

Por default, o recurso "Remember Me" cria um cookie chamado sfRemember que irá durar 15 dias. Você pode modificar este comportamento no app.yml:

    all:
      sf_guard_plugin:
         remember_key_expiration_age:  2592000   # 30 dias em segundos
         remember_cookie_name:         myAppRememberMe

Personalizando o redirecionamento do sfGuardAuth

Se você desejar redirecionar o usuário para seu profile após o login com sucesso ou definir um site para o logout. Você pode modificar os valores de redirecionamento no app.yml:

    all:
      sf_guard_plugin:
        success_signin_url:      @my_route?param=value # o plugin utiliza o referer como default
        success_signout_url:     module/action         # o plugin utiliza o referer como default

TODO

  • finish the promote_super_user task
  • finish the getPassword method
  • add support for HTTP Basic authentication

Changelog

1.1.13 PRE

1.1.12

  • fabien: fixed typo in secureSuccess template (closes #2260)
  • fabien: fixed 'secure' action in sfGuardPlugin do not need to be secure (closes #2254)
  • fabien: fixed typo in sfGuardUser::getProfile()
  • fabien: added some check in sfGuardSecurityUser proxy methods

1.1.11

  • fabien: fixed array_merge_recursive causes recursion warnings in sfGuardUser.php (closes #1834)
  • fabien: fixed groups, permissions, and profile saving when sfUser has no primary key (closes #1709)
  • fabien: added connection parameters to all methods that interacts with the database (closes #2237)
  • fabien: changed signout actions, so it doesn't require to be authenticated
  • fabien: added a ->isSuperAdmin() method to the User class
  • fabien: fixed connection should be used when saving model (closes #2152)
  • fabien: fixed typo in modules /sfGuardAuth/config/security.yml (closes #1930)
  • fabien: removed warning about foreign key and profile table
  • davedash: when displaying the signin form, if no referer is set for the user we default to the last page
  • davedash: updated documentation regarding remember me cookie settings (closes #2148)
  • davedash: default algorithm is now sha1 not \asha1\a (closes Ticket #2189)
  • davedash: made the default templates i18n compatible (closes #1662)

1.1.10

  • davedash: reordered the if/elseif structure so no loop starves

1.1.9

  • fabien: fixed a typo in sfGuardUser reloadGroupsAndPermissions() method (closes #1758)
  • fabien: fixed "Remember Me" filter documentation (closes #1705)

1.1.8

  • gordon: add two new config params 'success_signin_url' and 'success_signin_url'
  • gordon: split 'checkPassword()' to 'checkPassword()' and 'checkPasswordByGuard()' so it is callable by your own 'check_password()'
  • gordon: better redirect
  • gordon: 'login_module' and 'login_action' use for 'handleErrorSignin()' and after successe login
  • gordon: Added extra logic to make sure remember me code is only executed if user is not authenticated.
  • fabien: fixed is_super_admin has not default value (closes #1410)
  • fabien: fixed sfGuardPlugin signin.yml validation configuration (closes #1440)
  • fabien: fixed missing unique indexes in sf_guard_group and sf_guard_permission (closes #1454)
  • fabien: fixed sfGuardAuth should clear the credentials (closes #1537)
  • davedash: giving unique indexes unique names so that sfGuardPlugin works with postgres (closes ticket #1720)
  • davedash: fixed the model so getting groupPermissions works (fixes #1729)
  • davedash: the signin class would keep redirecting on itself if the user is logged in

1.1.7

  • fabien: fixed deleting sfGuardUser when no profile is defined (closes #1626)
  • davedash: The setPassword() function of sfGuardSecurityUser() now saves the sfGuardUser object after setting the password

Recent Visits: albuquerque new mexico hotels

iphone app developers dissertation help assignment help essay help custom dissertation