Sessão de Usuarios

Symfony gerencia automaticamente as sessões de usuários e mantem os dados persistentes entre as requisições. Usando o mecanismo interno do PHP e realça-os para fazê-los mais configuráveis e mais fáceis de usar.

Acessando a sessão de usuários

O objeto da sessão para o usuário atual é acessado na action com o método getUser() e é uma instância da classe sfUser. Esta classe contém um suporte do parâmetro que permita que você armazene todo o atributo do usuário nele. Estes dados estarão disponível a outros pedidos até o fim da sessão do usuário, como mostrado na lista 6-17. Os atributos do usuário podem armazenar qualquer tipo de dados (strings, arrays e arrays associativos). Podem ser ajustados para cada usuário individual, mesmo se esse usuário não for identificado.

Lista 6-17 - O objeto sfUser pode prender atributos customizados do usuário existentes através dos pedidos

<?php
    class mymoduleActions extends sfActions
    {
      public function executeFirstPage()
      {
        $nickname = $this->getRequestParameter('nickname');

        // Store data in the user session
        $this->getUser()->setAttribute('nickname', $nickname);
      }

      public function executeSecondPage()
      {
        // Retrieve data from the user session with a default value
        $nickname = $this->getUser()->getAttribute('nickname', 'Anonymous Coward');
      }
    }
?>

>Cuidado >Você pode armazenar objetos em uma seção de usuário, mas isto é extremamente desencorajado. Isto é porque o objeto de sessão é serializado entre a requisição e o armazenamento em um arquivo. Quando a sessão é deserializada, a classe dos objetos armazenados já deve estar carregada, e este não é sempre o caso.Além disso, pode haver objetos “parados” se você armazenar objetos Propel.

Como muitos getters no symfony, o método getAttribute() aceita um segundo argumento, o padrão é usado quando o atributo não é definido. Para checar se um atributo foi definido para um usuário, use o método hasAttribute(). O atributo está armazenado em um parâmetro quando pode ser acessado pelo método getAttributeHolder(). Isto permite acesso fácil dos atributos do usuário com o parâmetro usual, como mostrado na lista 6-18.

Lista 6-18 - Removendo dados da sessão de usuarios.

<?php

    class mymoduleActions extends sfActions
    {
      public function executeRemoveNickname()
      {
        $this->getUser()->getAttributeHolder()->remove('nickname');
      }

      public function executeCleanup()
      {
        $this->getUser()->getAttributeHolder()->clear();
      }
    }

?>

Os atributos da sessão de usuários estão disponível nos templates por padrão via a variável $sf_user, qual armazena o objeto atual sfUser, como mostrado na lista 6-19.

Lista 6-19 - Os templates têm também acesso aos atributos da sessão do usuário.

    <p>
      Hello, <?php echo $sf_user->getAttribute('nickname') ?>
    </p>

NOTA Se você precisa armazenar informação apenas durante o pedido, por exemplo, para passar informação através de chamadas de actions, você pode preferir a classe sfRequest, que também tem os métodos getAttribute() and setAttribute(). Somente os atributos do objeto são persistentes entre um request e outro.

Flash Attributes

Um problema recorrente com os atributos de usuários é a eliminação da sessão de usuários sempre que os dados não são mais necessários. Por exemplo, você precisa mostrar uma confirmação depois de atualizar dados via formulário. Como o action faz um redirecionamento, a unica maneira de passar informação deste action para onde ele for redirecionado é armazenar a informação na sessão do usuário. Mas assim que a mensagem for exibida, você precisa limpar o atributo; senão, ele continuara atá a expiração da sessão.

O atributo flash é efemeral, você pode defini-lo e esquece-lo, sabendo que ele desaparecerá no próximo request e deixará a sessão do usuário limpa. Na sua action, defina o atributo flash assim:

<?php
    $this->setFlash('attrib', $value);
?>

O template será renderizado e entregue ao usuário, quando ele fizer um novo pedido em outro action. Neste segundo action, apenas recupere o valor do flash assim:

<?php
    $value = $this->getFlash('attrib');
?>

Então se esqueça dele. Após entregar esta segunda pagina, o atributo flash será reiniiciado. E mesmo se você não o requerer durante esta segunda ação, o flash desaparecerá da sessão do usuário de qualquer forma.

Se você precisa acessar um atributo flash de um template, use o objeto $sf_flash:

    <?php if ($sf_flash->has('attrib')): ?>
      <?php echo $sf_flash->get('attrib') ?>
    <?php endif; ?>

ou:

    <?php echo $sf_flash->get('attrib') ?>

Os atributos do flash são uma maneira limpa de passar a informação ao pedido seguinte.

Gerenciamento de sessões

O gerenciador de sessão do symfony

_Symfony's session-handling feature completely masks the client and server storage of the session IDs to the developer. However, if you want to modify the default behaviors of the session-management mechanisms, it is still possible. This is mostly for advanced users._

On the client side, sessions are handled by cookies. The symfony session cookie is called symfony, but you can change its name by editing the factories.yml configuration file, as shown in Listing 6-20.

Listing 6-20 - Changing the Session Cookie Name, in apps/myapp/config/factories.yml

all:

storage:

class: sfSessionStorage param:

session_name: my_cookie_name

**TIP** The session is started (with the PHP function session_start()) only if the auto_start parameter is set to true in factories.yml (which is the case by default). If you want to start the user session manually, disable this setting of the storage factory.

Symfony's session handling is based on PHP sessions. This means that if you want the client-side management of sessions to be handled by URL parameters instead of cookies, you just need to change the use_trans_sid setting in your php.ini. Be aware that this is not recommended.

session.use_trans_sid = 1

On the server side, symfony stores user sessions in files by default. You can store them in your database by changing the value of the class parameter in factories.yml, as shown in Listing 6-21.

Listing 6-21 - Changing the Server Session Storage, in apps/myapp/config/factories.yml

all:

storage:

class: sfMySQLSessionStorage param:

db_table: SESSION_TABLE_NAME # Name of the table storing the sessions database: DATABASE_CONNECTION # Name of the database connection to use

The available session storage classes are sfMySQLSessionStorage, sfPostgreSQLSessionStorage, and sfPDOSessionStorage; the latter is preferred. The optional database setting defines the database connection to be used; symfony will then use databases.yml (see Chapter 8) to determine the connection settings (host, database name, user, and password) for this connection.

Session expiration occurs automatically after sf_timeout seconds. This constant is 30 minutes by default and can be modified for each environment in the settings.yml configuration file, as shown in Listing 6-22.

Listing 6-22 - Changing Session Lifetime, in apps/myapp/config/settings.yml

default:

.settings:

timeout: 1800 # Session lifetime in seconds

« Anterior índice do Capitulo Seguinte »