Sesja PHP została utracona po przekierowaniu

Jak rozwiązać problem utraty sesji po przekierowaniu w PHP?

Ostatnio napotkałem bardzo częsty problem z utratą sesji po przekierowaniu. A po przeszukaniu tej strony nadal nie mogę znaleźć rozwiązania (chociaż to było najbliższe).

Aktualizacja

Znalazłem odpowiedź i pomyślałem, że opublikuję ją tutaj, aby pomóc każdemu, kto ma ten sam problem.

Najpierw przeprowadź te zwykłe kontrole:

1. Upewnij się, że session_start();jest wywoływana przed wywołaniem jakichkolwiek sesji. Więc bezpiecznym zakładem byłoby postawienie go na początku strony, bezpośrednio po <?phpdeklaracji otwarcia, przed czymkolwiek innym. Upewnij się również, że przed <?phpdeklaracją otwierającą nie ma spacji / tabulatorów .
2. Po headerprzekierowaniu zakończ bieżący skrypt za pomocą exit();(inni również zasugerowali session_write_close();i session_regenerate_id(true)możesz też spróbować, ale ja bym użył exit();)
3. Upewnij się, że pliki cookie są włączone w przeglądarce, której używasz do testowania.
4. Upewnij register_globalssię, że jest wyłączone, możesz to sprawdzić w php.inipliku, a także za pomocą phpinfo(). Zapoznaj się z tym, jak go wyłączyć.
5. Upewnij się, że nie usunąłeś ani nie opróżniłeś sesji
6. Upewnij się, że klucz w twojej $_SESSIONsuperglobalnej tablicy nie został nigdzie nadpisany
7. Upewnij się, że przekierowujesz do tej samej domeny. Zatem przekierowanie z a www.yourdomain.comdo yourdomain.comnie przenosi sesji do przodu.
8. Upewnij się, że rozszerzenie pliku to .php(zdarza się!)

To są najczęstsze błędy, ale jeśli nie pomogły, problem najprawdopodobniej dotyczy Twojej firmy hostingowej. Jeśli wszystko działa, localhostale nie na serwerze zdalnym / testowym, najprawdopodobniej jest to przyczyną. Sprawdź więc bazę wiedzy swojego dostawcy usług hostingowych (wypróbuj także jego fora itp.). W przypadku firm takich jak FatCow i iPage wymagają one określenia session_save_path. Więc tak:

session_save_path('"your home directory path"/cgi-bin/tmp');
session_start();

(Zastąp „ścieżkę do katalogu domowego” rzeczywistą ścieżką do katalogu domowego. Zwykle znajduje się ona w panelu sterowania (lub jego odpowiedniku), ale możesz też utworzyć test.phpplik w katalogu głównym i wpisać:

<?php echo $_SERVER['SCRIPT_FILENAME']; ?>

Bit przed „test.php” to ścieżka do katalogu domowego. I oczywiście upewnij się, że folder faktycznie istnieje w katalogu głównym. (Niektóre programy nie przesyłają pustych folderów podczas synchronizacji)

powinieneś użyć „exit” po wywołaniu nagłówka

header('Location: http://www.example.com/?blabla=blubb');
exit;

Wypróbowałem wszystkie możliwe rozwiązania, ale żadne nie zadziałało! Oczywiście korzystam z usługi hostingu współdzielonego.

W końcu udało mi się obejść problem, używając „względnego adresu URL” w nagłówku przekierowania!

header("location: http://example.com/index.php")

anulował sesyjne pliki cookie

header("location: index.php")

działało jak urok!

Miałem ten sam problem. Pracowałem nad tym kilka godzin i doprowadzało mnie to do szału.

W moim przypadku problem polegał na wywołaniu 404 z powodu braku favicon.ico tylko w Chrome i Firefox. Inni nawigatorzy działali dobrze.

Miałem ten sam problem. Nagle NIEKTÓRE z moich zmiennych sesji nie były przenoszone na następną stronę. Okazało się, że (w php7.1) lokalizacja nagłówka nie może zawierać WWW, np. Https: // mysite . jest w porządku, https: //www.mysite . utraci zmienne sesji tych stron. Nie wszystko, tylko ta strona.

Kiedy używam ścieżki względnej "dir / file.php" z funkcją header () w działa dla mnie. Myślę, że sesja nie jest z jakiegoś powodu zapisywana, gdy przekierowujesz przy użyciu pełnego adresu URL ...

//Does retain the session info for some reason
header("Location: dir");

//Does not retain the session for some reason
header("Location: https://mywebz.com/dir")

Miałem podobny problem, chociaż mój kontekst był nieco inny. Miałem lokalną konfigurację programistyczną na komputerze, którego nazwa hosta windowsi adres IP to192.168.56.2 .

Mogłem uzyskać dostęp do systemu za pomocą jednego z następujących sposobów:

• http: // localhost /
• http://127.0.0.1/
• http: // windows /
• http://192.168.56.2/

Po zalogowaniu mój kod PHP przekierowałby za pomocą:

header('http://windows/');

Gdyby poprzednia nazwa domeny używana do uzyskania dostępu do systemu nie była windows, dane sesji zostałyby utracone. Rozwiązałem to, zmieniając kod na:

header('http://'.$_SERVER['HTTP_HOST'].'/');

Teraz działa niezależnie od nazwy domeny lokalnej lub adresu IP wprowadzonego przez użytkownika.

Mam nadzieję, że komuś się to przyda.

Natknąłem się na ten problem na jednej konkretnej stronie. Ustawiałem wartości $ _SESSION na innych stronach tuż przed przekierowaniem i wszystko działało dobrze. Ale ta konkretna strona nie działała.

W końcu zdałem sobie sprawę, że na tej konkretnej stronie niszczyłem sesję na początku strony, ale nigdy nie zaczynałam jej ponownie. Więc moja funkcja niszczenia zmieniła się z:

function sessionKill(){

    session_destroy();

}

do:

function sessionKill(){

    session_destroy();
    session_start();

}

I wszystko działało!

Długo mnie to martwiło (a ten post był świetny do znalezienia!), Ale dla każdego, kto nadal nie może uzyskać sesji między przekierowaniami stron do pracy ... Musiałem wejść do pliku php.ini i włączyć pliki cookie :

session.use_cookies = 1 

Myślałem, że sesje działają bez ciasteczek ... tak naprawdę wiem, że POWINNY ... ale to rozwiązało mój problem przynajmniej do czasu, gdy rozumiem, co może się dziać w szerszym kontekście.

Zmagałem się z tym od dni, sprawdzając / próbując wszystkich rozwiązań, ale mój problem polegał na tym, że nie zadzwoniłem session_start(); po przekierowaniu ponownie. Po prostu założyłem, że sesja „wciąż żyje”.

Więc nie zapomnij o tym!

Miałem ten sam problem i znalazłem najłatwiejszy sposób. Po prostu przekierowałem do przekierowania .html z 1 linią JS

<!DOCTYPE html>
<html>
<script type="text/javascript">
<!--
window.location = "admin_index.php";
//–>
</script>
</html>

zamiast PHP

header_remove();
header('Location: admin_login.php');
die;

Mam nadzieję, że to pomoże.

Kocham Gram

Jeśli używasz, session_set_cookie_params()możesz chcieć sprawdzić, czy przekazujesz czwarty parametr $securejako true. Jeśli tak, musisz uzyskać dostęp do adresu URL za pomocą protokołu https.

Jeśli $secureparametr jest prawdziwy, oznacza to, że sesja jest dostępna tylko w ramach bezpiecznego żądania. Może to wpłynąć na Ciebie bardziej lokalnie niż w środowiskach scenicznych lub produkcyjnych.

Wspominając o tym, ponieważ spędziłem większość dnia na szukaniu tego problemu i właśnie to rozwiązało go dla mnie. Właśnie zostałem dodany do tego projektu i nikt nie wspomniał, że wymaga on https.

Możesz więc użyć protokołu https lokalnie lub ustawić $secureparametr na, FALSEa następnie użyć protokołu http lokalnie. Po prostu pamiętaj, aby ustawić ją z powrotem na prawdę, gdy wprowadzisz zmiany.

W zależności od lokalnego serwera może być konieczna edycja DocumentRootw pliku httpd-ssl.confserwera, aby lokalny adres URL był obsługiwany jako https.

Inny możliwy powód:

To jest moje miejsce na serwerze. Moje miejsce na dysku serwera zostało zapełnione. Więc usunąłem kilka plików i folderów na moim serwerze i spróbowałem.

Udało się !!!

Zapisuję sesję w AWS Dynamo DB, ale nadal oczekuje trochę miejsca na moim serwerze, aby przetworzyć sesję. Nie pewny dlaczego!!!

Jeśli używasz Laravel i napotykasz ten problem, musisz zapisać dane sesji przed przekierowaniem.

session()->save();
// Redirect the user to the authorization URL.
header('Location: ' . $authorizationUrl);
exit;

Miałem również ten sam problem z niedziałającym przekierowaniem i wypróbowałem wszystkie rozwiązania, które mogłem znaleźć, moje przekierowanie nagłówka było używane w formularzu.

Rozwiązałem to, umieszczając przekierowanie nagłówka na innej stronie php „signin_action.php” i przekazując parametry zmiennych przez, które chciałem w parametrach adresu URL, a następnie ponownie przypisując je w formularzu „signin_action.php”.

signin.php

if($stmt->num_rows>0) {
$_SESSION['username'] = $_POST['username'];
echo '<script>window.location.href = "http://'.$root.'/includes/functions/signin_action.php?username='.$_SESSION['username'].'";</script>';
error_reporting(E_ALL);

signin_action.php

<?php
require('../../config/init.php');
$_SESSION['username'] = $_GET['username'];
if ($_SESSION['username']) {

echo '<script>window.location.href = "http://'.$root.'/user/index.php";</script>';
exit();
} else {
echo 'Session not set';
}

?>

Nie jest to piękne obejście, ale zadziałało.

U mnie błąd polegał na tym, że próbowałem zapisać w sesji obiekt, którego nie można było serializować, aby podczas próby zapisu sesji został wyrzucony wyjątek. Ale ponieważ cały mój kod obsługi błędów już przerwał jakąkolwiek operację, nigdy nie widziałem błędu.

Mogłem jednak znaleźć to w dziennikach błędów Apache.

Tak dla porządku ... miałem ten problem i po kilku godzinach próbowania wszystkiego problem polegał na tym, że dysk był pełny, a sesje php nie mogły zostać zapisane w katalogu tmp ... więc jeśli masz ten problem, sprawdź to też...

Dla mnie Firefox zapisał identyfikator sesji (PHPSESSID) w pliku cookie, ale Google Chrome użył parametru GET lub POST. Musisz więc tylko upewnić się, że skrypt zwracający (dla mnie: paypal checkout) zatwierdzi PHPSESSID w parametrze url lub POST.

Po wypróbowaniu wielu rozwiązań tutaj na SO i innych blogach ... zadziałało dodanie .htaccess do katalogu głównego mojej witryny.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^yoursitename.com$
RewriteRule ^.*$ "http\:\/\/www\.yoursitename\.com" [R=301,L]

Jeśli używasz Wordpressa, musiałem dodać ten hook i rozpocząć sesję na init:

function register_my_session() {
    if (!session_id()) {
        session_start();
    }
}
add_action('init', 'register_my_session');

Nic nie działało, ale znalazłem przyczynę problemu (i rozwiązałem go):

Sprawdź pliki cookie swojej przeglądarki i upewnij się, że nie ma plików cookie sesji php w różnych subdomenach (np. Jedna dla „ www.website.com ” i jedna dla „ website.com ”).

Było to spowodowane przez skrypt javascript, który nieprawidłowo używał subdomeny do ustawiania plików cookie i otwierania stron w ramkach iframe.

Przede wszystkim upewnij się, że dzwonisz session_start()przed użyciem $_SESSIONzmiennej.

Jeśli wyłączyłeś raportowanie błędów, spróbuj go włączyć i zobacz wynik.

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Najczęstsze przyczyny, które nie zostały wymienione w odpowiedzi @ dayuloli:

1. Problem z miejscem na dysku. Upewnij się, że miejsce na dysku nie jest pełne, potrzebujesz trochę miejsca do przechowywania plików sesji.

2. Katalog sesji może nie być zapisywalny. Możesz to sprawdzićis_writable(session_save_path())

Miałem ten sam problem i oszalałem, szukając odpowiedzi w swoim kodzie. W końcu odkryłem, że mój hosting niedawno zaktualizował wersję PHP na moim serwerze i nie ustawił poprawnie session_save_pathparametru w php.inipliku.

Więc jeśli ktoś to przeczyta, sprawdź php.ininajpierw konfigurację.

Upewnij się, że session_write_closenie jest wywoływany pomiędzy session_start()i podczas ustawiania sesji.

session_start();

[...]

session_write_close();

[...]

$_SESSION['name']='Bob'; //<-- won't save

Teraz, gdy RODO jest już rzeczą, osoby odwiedzające to pytanie prawdopodobnie używają skryptu cookie. Cóż, ten skrypt spowodował dla mnie problem. Najwyraźniej PHP wykorzystuje plik cookie o nazwiePHPSESSID do śledzenia sesji. Jeśli ten skrypt go usunie, utracisz swoje dane.

Użyłem tego skryptu cookie . Posiada opcję włączenia „niezbędnych” plików cookie. dodałemPHPSESSID do listy, skrypt przestał usuwać ciasteczko i wszystko znów zaczęło działać.

Prawdopodobnie możesz włączyć niektóre ustawienia PHP, aby uniknąć używania PHPSESSID, ale jeśli przyczyną problemu jest skrypt cookie, dlaczego nie naprawić tego .

Naprawiłem ten problem po wielu dniach debugowania, a to wszystko dlatego, że mój zwrotny adres URL pochodzący z PayPal Express Checkout nie miał „www”. Chrome uznał, że domeny powinny być traktowane tak samo, ale inne przeglądarki czasami nie. Korzystając z sesji / plików cookie i ścieżek bezwzględnych, nie zapomnij o „www”!

Naprawiłem, dając grupie uprawnienia do zapisu do ścieżki, w której PHP przechowuje pliki sesji. Możesz znaleźć ścieżkę sesji za pomocą funkcji session_save_path ().

Dzisiaj miałem ten problem w projekcie i musiałem zmienić ten parametr na false (lub usunąć linie, domyślnie jest wyłączona):

ini_set( 'session.cookie_secure', 1 );

Stało się tak, ponieważ rzeczywisty projekt działa przez http, a nie tylko https. Więcej informacji można znaleźć w dokumentach http://php.net/manual/en/session.security.ini.php

ini_set('session.save_path',realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
session_start();

Za późno na odpowiedź, ale to zadziałało

Dla mnie to był błąd uprawnień i to rozwiązało problem:

chown -R nginx: nginx / var / opt / remi / php73 / lib / php / session

Testowałem kilka godzin na PHP, a ostatnim testem, który zrobiłem, było utworzenie dwóch plików session1.php i session2.php.

session1.php:

session_start();

$_SESSION["user"] = 123;

header("Location: session2.php");

session2.php:

session_start();

print_r($_SESSION);

i wypisuje pustą tablicę.

W tym momencie pomyślałem, że może to być problem z serwerem i faktycznie tak było.

Mam nadzieję, że to komuś pomoże.