Os dados da sessão PHP não ser salvo
https://stackoverflow.com/questions/155920
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu tenho um daqueles "Eu juro que não tocou o servidor" situações. Sinceramente, não toque em nenhum dos scripts PHP. O problema que estou tendo é que os dados php não está sendo salvo em diferentes páginas ou atualiza a página. Eu sei que uma nova sessão está sendo criado corretamente porque eu posso definir uma variável de sessão (por exemplo, $ _SESSION [ 'foo'] = "foo" e imprimi-lo de volta na mesma página muito bem. Mas quando eu tento usar a mesma variável em outra página que não está definido! existe quaisquer funções ou informações que eu posso usar no meu servidor anfitriões para ver o que está acontecendo em php?
Aqui está um script de exemplo que não funciona no servidor dos meus anfitriões a partir de agora:
<?php
session_start();
if(isset($_SESSION['views']))
$_SESSION['views'] = $_SESSION['views']+ 1;
else
$_SESSION['views'] = 1;
echo "views = ". $_SESSION['views'];
echo '<p><a href="page1.php">Refresh</a></p>';
?>
A variável 'vistas' nunca é incrementado depois de fazer uma atualização de página. Eu estou pensando que este é um problema do seu lado, mas eu queria ter certeza que eu não sou um idiota completo em primeiro lugar.
Aqui está o phpinfo () para o servidor dos meus anfitriões (PHP versão 4.4.7):
Solução
Obrigado por todas as informações úteis. Acontece que meu anfitrião mudou servidores e começou a usar uma sessão diferente salvar caminho diferente de / var / php_sessions que não existe mais. Uma solução seria a declarar ini_set(' session.save_path','SOME WRITABLE PATH'); em todos os meus arquivos de script, mas que teria sido uma dor. Falei com o anfitrião e eles definir explicitamente o caminho de sessão para um caminho real que existia. Espero que isso ajude alguém que tem problemas de caminho sessão.
Outras dicas
Certifique-se de que você não está misturando https: // com o http: //. As variáveis ??de sessão não fluem entre sessões seguras e inseguras.
Tive mesmo problema - o que me aconteceu é o nosso administrador do servidor mudou o boolean session.cookie_secure para On, o que significa que os cookies só serão enviados através de uma conexão segura. Desde o cookie não estava sendo encontrado, php estava criando uma nova sessão de cada vez, portanto, variáveis ??de sessão não estavam a ser visto.
Use phpinfo() e verifique as configurações session.*.
Talvez as informações são armazenadas em cookies e seu navegador não aceita cookies, algo assim.
Verifique se primeiro e voltar com os resultados.
Você também pode fazer uma print_r($_SESSION); ter um despejo desta variável e ver o conteúdo ....
Quanto à sua phpinfo(), é a session.save_path um válido? Será que o seu servidor web tem acesso de gravação para este diretório?
Espero que isso ajude.
Eu tinha problema seguinte
index.php
<?
session_start();
$_SESSION['a'] = 123;
header('location:index2.php');
?>
index2.php
<?
session_start();
echo $_SESSION['a'];
?>
O $_SESSION['a'] variável não foi definida corretamente. Então eu mudei o index.php acordingly
<?
session_start();
$_SESSION['a'] = 123;
session_write_close();
header('location:index2.php');
?>
Eu não sei o que isso internamente meio, eu só explicar isso para mim mesmo que a mudança variável de sessão não foi suficiente rápida:)
Verifique se a sessão salvar caminho é escrito pelo servidor web.
Certifique-se de ter cookies ativados .. (eu me esquecer quando eu desligá-los para testar algo)
Use o Firefox com a extensão Firebug para ver se o cookie está sendo definido e volta transmitido.
E em uma nota não relacionada, começar a olhar para php5, porque o PHP 4.4.9 é o último da série php4.
Verifique que o grupo eo proprietário são da pasta onde o script é executado. Se o ID de grupo ou ID de usuário está errado, por exemplo, definir a raiz, ele fará sessões para não ser salvo corretamente.
Verifique o valor de "visões" quando antes de incrementá-lo. Se, por alguma razão bizarra, está ficando pronto para uma corda, em seguida, quando você adiciona 1 a ela, ele vai sempre retornar 1.
if (isset($_SESSION['views'])) {
if (!is_numeric($_SESSION['views'])) {
echo "CRAP!";
}
++$_SESSION['views'];
} else {
$_SESSION['views'] = 1;
}
Bem, podemos eliminar o erro código porque eu testei o código em meu próprio servidor (PHP 5).
Aqui está o que para verificar se:
-
Você está chamando session_unset () ou session_destroy em qualquer lugar ()? Estas funções irá apagar os dados da sessão imediatamente. Se eu colocá-los no final do meu script, ele começa a se comportar exatamente como você descreve.
-
Será que agem da mesma em todos os navegadores? Se ele funciona em um navegador e não outro, você pode ter um problema de configuração no navegador nonfunctioning (ou seja, você desligou os cookies e se esqueceu de ligá-los, ou estão a bloquear os cookies por engano).
-
É o gravável pasta sessão? Você não pode testar isso com is_writable (), então você precisa ir para a pasta (de phpinfo () parece como / var / php_sessions) e fazer sessões de certeza que estão realmente recebendo criado.
Se você definir uma sessão em PHP5, em seguida, tentar lê-lo em uma página php4, pode não olhar no lugar correto! Faça as páginas a mesma versão php ou definir o session_path.
I passado as idades procurando a resposta para um problema similar. Não foi um problema com o código ou a configuração, como um código muito semelhante funcionou perfeitamente em outro .php no mesmo servidor. Acabou o problema foi causado por uma quantidade muito grande de dados que estão sendo salvos para a sessão desta página. Em um lugar que tinha uma linha da seguinte forma: $_SESSION['full_list'] = $full_list onde $full_list era uma matriz de dados carregados a partir da base de dados; cada linha foi uma matriz de cerca de 150 elementos. Quando o código foi inicialmente escrito um par de anos atrás, a DB só continha cerca de 1000 linhas, de modo que o $full_list continha cerca de 100 elementos, sendo cada um conjunto de cerca de 20 elementos. Com o tempo, os elementos 20 se transformou em 150 e 1000 linhas transformadas em 17 mil, de modo que o código foi armazenamento perto de 64 meg de dados para a sessão. Aparentemente, com esta quantidade de dados armazenados, ele recusou-se a loja de qualquer outra coisa. Uma vez que mudou o código para lidar com dados localmente sem salvá-lo para a sessão, tudo funcionou perfeitamente.
Eu sei que uma solução que eu encontrei (OSX com Apache 1 e apenas mudou para PHP5), quando eu tive um problema semelhante foi essa chave desactivação 1 específica (ou seja, unset ($ _ SESSION [ 'chave']);) estava causando isso não salvar. Assim que eu fiz não apaga a chave mais ele salvou. Eu nunca vi isso de novo, exceto no servidor em outro site, mas depois foi uma variável diferente. Nem eram nada de especial.
Obrigado por este Darryl. Isso me ajudou a sair. I foi a exclusão de uma variável de sessão, e por alguma razão ele estava mantendo a sessão de cometer. Agora eu estou apenas defini-lo como nulo em vez (o que é bom para o meu app), e ele funciona.
Eu sei que uma solução que eu encontrei (OSX com Apache 1 e apenas mudou para PHP5), quando eu tive um problema semelhante foi essa chave desactivação 1 específica (ou seja, unset ($ _ SESSION [ 'chave']);) estava causando isso não salvar. Assim que eu fiz não apaga a chave mais ele salvou. Eu nunca vi isso de novo, exceto no servidor em outro site, mas depois foi uma variável diferente. Nem eram nada de especial.
Aqui é um problema comum Eu não vi abordados em outros comentários: é o seu host executando um cache de algum tipo? Se eles são cache automaticamente os resultados de alguma forma você teria este tipo de comportamento.
Só queria acrescentar uma pequena nota que isso também pode ocorrer se você acidentalmente perder a declaração session_start () em suas páginas.
Tive sessão de cookie conjunto caminho para "//" em vez de "/". Firebug é incrível. Espero que ajude alguém.
Eu tive esse problema ao usar páginas seguras onde eu estava vindo de www.domain.com/auth.php que redirecionado para domain.com/destpage.php. Eu removi o www partir do link auth.php e funcionou. Isso me jogou porque tudo trabalhados de outro modo; a sessão não foi definido quando cheguei ao destino embora.
Um problema comum muitas vezes esquecido também que deve haver nenhum outro código ou o espaçamento extra antes de o comando session_start ().
Eu tive esse problema antes de onde eu tinha uma linha em branco antes session_start () que causou que ele não funcione corretamente.
Adicionando a minha solução:
Verifique se você acessar o domínio correto . Eu estava usando www.mysite.com para iniciar a sessão, e tentou recebê-lo de mysite.com (sem o www).
Eu ter resolvido isso adicionando uma reescrita htaccess de todos os domínios para www estar no seguro lado / site.
Além disso, verifique se você usar HTTP ou HTTPS.
Editar seu php.ini.
Eu acho que o valor de session.gc_probability é 1, então configurá-lo para 0.
session.gc_probability=0
Verifique se você estiver usando session_write_close (); em qualquer lugar, eu estava usando esse direito depois de outra sessão e, em seguida, tentar escrever a sessão novamente e ele não estava funcionando .. assim apenas comentar que sh * t fora
Outra algumas coisas que eu tinha que fazer (eu tinha mesmo problema: nenhuma retenção sesson após PHP upgrade para 5.4). Você muitos não precisar deles, dependendo do que php.ini do servidor contém (phpinfio verificação ());
session.use_trans_sid=0 ; Do not add session id to URI (osc does this)
session.use_cookies=0; ; ensure cookies are not used
session.use_only_cookies=0 ; ensure sessions are OK to use IMPORTANT
session.save_path=~/tmp/osc; ; Set to same as admin setting
session.auto_start = off; Tell PHP not to start sessions, osc code will do this
Basicamente, o seu php.ini deve ser definida para nenhum cookie, e parâmetros de sessão deve ser coerente com o que osc quer.
Você também pode precisar de mudar alguns trechos de código sessão em application_top.php - a criação de objetos onde eles não existem nos tep_session_is_registered (...) as chamadas (e por exemplo, navegação objeto.), Definir variáveis ??HTTP_ $ a $ _SERVER mais recente queridos e alguns outros testes isset para objetos vazios (google para info). I acabou sendo capaz de usar os arquivos sessions.php originais (inclui / aulas e inclui / funções) com um application_top.php ligeiramente modificado para começar as coisas novamente. As configurações do php.ini foram o principal problema, mas isso, claro, depende do que a sua empresa servidor foi instalado como padrão.
