Помощь в сохранении сессий PHP после переноса за пределы сайта - PullRequest
1 голос
/ 27 мая 2010

мы работаем над системой платежного шлюза с PHP. Мы используем сеансы для хранения данных корзины покупок. Система переместит вас за пределы сайта на сайт обработчика платежей, а затем вернет вас на ваш сайт. На большинстве хостов у нас нет проблем, когда мы возвращаемся на наш сайт и сохраняем данные сеанса. Для тех, у кого есть проблема, отключение PHP-сессии referer_check работало в прошлом. Мы действительно не хотим включать PHPSESSID в качестве переменной GET и надеемся избежать этого. То, что я ищу, - это то, какие конфигурации других серверов могут привести к прекращению сеанса, и любые другие обходные пути, которые там могут быть.

Спасибо за вашу помощь.

Ответы [ 5 ]

1 голос
/ 27 мая 2010

Использование сеансов на основе файлов cookie имеет несколько возможностей:

  • Для какого домена настроен файл cookie? mysite.com и secure.mysite.com - это не одно и то же.
  • Возникает ли проблема во всех веб-браузерах для данного веб-хоста?
  • Вы звоните session_regenerate_id в любой момент?
  • Записываете ли вы cookie сеанса и перенаправляете ли вы на обработчик платежей с той же страницы PHP? Возможно, веб-хост не отправляет правильные заголовки. Я бы предложил загрузить Firebug и убедиться, что cookie-файл сеанса в браузере соответствует текущему идентификатору сеанса на сервере.
  • Когда вы запускаете phpinfo() на проблемном веб-хосте, действительно ли session.refer_check имеет желаемое значение?

Там много возможностей. Вот все связанные с сеансом настройки времени выполнения PHP, многие из которых могут вызывать проблемы:

http://www.php.net/manual/en/session.configuration.php

0 голосов
/ 29 июня 2010

Что касается проблемы тайм-аута сеанса, то это должен быть промежуток времени, настроенный на сервере. Возможно, вам придется просмотреть файл php.ini на сервере.

Я должен знать, что на этот раз может измениться следующее:

php_value session.gc_maxlifetime 72000 /* I have not tested this */

Я думаю, что вы можете использовать мой метод для создания идентификатора отпечатка пальца в сеансе пользователя, используя следующий скрипт на странице перед выходом с сайта и возвращением страницы.

$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'GHYU&*%HHD#JSFHJJFD(*JFJ'; // any long value
        /* Add any other data that is consistent */
$fingerprint = md5($string);



if (isset($_SESSION['HTTP_USER_AGENT']))
    {
        if ($_SESSION['HTTP_USER_AGENT'] !== $fingerprint)
        {
            /* Prompt for password */
            session_destroy();
            header("Location:"."URL/PATH/TO/LOGIN");
        }
    }
else
    {   
        $_SESSION['HTTP_USER_AGENT'] = $fingerprint;
}
0 голосов
/ 29 мая 2010

Нет cookie, нет сеанса, просто используйте уникальный идентификатор, отправленный в качестве дополнительного параметра или атрибута в платежную систему (обычно это может сделать идентификатор tx), на странице возврата url напишите функцию для определения полученного уникального идентификатора и сравнения, если true, создайте новый сеанс для пользователя.

0 голосов
/ 27 мая 2010

Это очень теневая область безопасности PHP - как сохранить сеанс, не раскрывая cookie или идентификатор сеанса в URL? К сожалению, единственное безопасное решение - использование куки, но я постараюсь объяснить, как сделать его максимально безопасным.

Перед тем, как пользователь покинет сайт, вам необходимо подготовить базу данных для ее принятия без необходимости повторного ввода данных для входа в систему - создайте в своей пользовательской таблице два столбца - «ключ» и «время ожидания».

Теперь, когда пользователь готовится покинуть сайт через ваш платежный шлюз, вам необходимо обновить свою запись в базе данных - сгенерировать уникальный ключ для хранения.

$key = md5(uniqid(rand(), true));

Сохраните это в базе данных вместе с тайм-аутом (скажем, час, два или даже целый день - все, что вам нужно). Пока они возвращаются в течение указанного периода времени и могут выдать правильный ключ, система будет продолжать распознавать пользователя, и вам не придется беспокоиться о повторном входе в систему.

Теперь нам нужно установить cookie с тем же ключом и, скажем, соленый хэш md5 их имени пользователя (на всякий случай). Не забудьте указать тот же тайм-аут, который вы указали в базе данных (вы не хотите, чтобы старые файлы cookie с конфиденциальной информацией валялись вечно).

Как только они вернутся на сайт, возьмите cookie с уникальным идентификатором и хэшированным именем пользователя и сравните его с комбинацией ключ / тайм-аут в вашей базе данных. Если они совпадают, все хорошо. Затем удалите куки.

0 голосов
/ 27 мая 2010

У меня возникла та же проблема, и она была связана в основном с временем жизни cookie и доменом cookie, например, www.example.org отличается от example.org для IE.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...