Você deve implementar seu próprio tempo limite da sessão. Ambas as opções mencionadas por outras pessoas ( session.gc_maxlifetime e session.cookie_lifetime ) não são confiáveis. Eu vou explicar as razões para isso.
Primeiro:
session.gc_maxlifetime
session.gc_maxlifetime especifica o número de segundos após os quais os dados serão vistos como 'lixo' e limpos. A coleta de lixo ocorre durante o início da sessão.
Mas o coletor de lixo é iniciado apenas com uma probabilidade de session.gc_probability dividida por session.gc_divisor . E usando os valores padrão para essas opções (1 e 100 respectivamente), a chance é de apenas 1%.
Bem, você pode simplesmente ajustar esses valores para que o coletor de lixo seja iniciado com mais frequência. Mas quando o coletor de lixo é iniciado, ele verifica a validade de cada sessão registrada. E isso custa muito.
Além disso, ao usar os arquivos session.save_handler padrão do PHP , os dados da sessão são armazenados nos arquivos em um caminho especificado em session.save_path . Com esse manipulador de sessão, a idade dos dados da sessão é calculada na data da última modificação do arquivo e não na data do último acesso:
Nota: Se você estiver usando o manipulador de sessões baseado em arquivo padrão, seu sistema de arquivos deve acompanhar os tempos de acesso (atime). O Windows FAT não funciona, portanto você terá que criar outra maneira de lidar com a coleta de lixo da sua sessão, se você estiver com um sistema de arquivos FAT ou qualquer outro sistema de arquivos em que o rastreamento de atime não esteja disponível. Desde o PHP 4.2.3, ele usa mtime (data de modificação) em vez de atime. Portanto, você não terá problemas com sistemas de arquivos nos quais o atime tracking não está disponível.
Portanto, adicionalmente, pode ocorrer que um arquivo de dados da sessão seja excluído enquanto a própria sessão ainda é considerada válida porque os dados da sessão não foram atualizados recentemente.
E em segundo lugar:
session.cookie_lifetime
session.cookie_lifetime especifica o tempo de vida do cookie em segundos, que é enviado ao navegador. [...]
Sim está certo. Isso afeta apenas a vida útil do cookie e a própria sessão ainda pode ser válida. Mas é tarefa do servidor invalidar uma sessão, não o cliente. Então isso não ajuda em nada. De fato, ter session.cookie_lifetime definido como 0tornaria o cookie da sessão um cookie de sessão real , válido apenas até o navegador ser fechado.
Conclusão / melhor solução:
A melhor solução é implementar seu próprio tempo limite de sessão. Use um registro de data e hora simples que indique a hora da última atividade (ou seja, solicitação) e atualize-a com cada solicitação:
if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1800)) {
// last request was more than 30 minutes ago
session_unset(); // unset $_SESSION variable for the run-time
session_destroy(); // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp
A atualização dos dados da sessão com cada solicitação também altera a data de modificação do arquivo da sessão, para que a sessão não seja removida pelo coletor de lixo prematuramente.
Você também pode usar um carimbo de data / hora adicional para gerar novamente o ID da sessão periodicamente para evitar ataques a sessões como a fixação da sessão :
if (!isset($_SESSION['CREATED'])) {
$_SESSION['CREATED'] = time();
} else if (time() - $_SESSION['CREATED'] > 1800) {
// session started more than 30 minutes ago
session_regenerate_id(true); // change session ID for the current session and invalidate old session ID
$_SESSION['CREATED'] = time(); // update creation time
}
Notas:
session.gc_maxlifetime deve ser pelo menos igual ao tempo de vida desse manipulador de expiração personalizado (1800 neste exemplo);- se você quiser expirar a sessão após 30 minutos de atividade, em vez de após 30 minutos desde o início , também precisará usar
setcookiecom um prazo de validade time()+60*30para manter o cookie da sessão ativo.