PHP сессия без куки

Есть ли способ, которым я могу инициировать постоянный сеанс в PHP без размещения cookie сеанса? Существуют ли другие способы поддержки сеанса на разных страницах, например решение на основе IP-адреса?

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

Ответы на вопрос(7)

Решение Вопроса

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

В противном случае вы можете установитьsession.use_only_cookies на «0», чтобы принудительно добавить идентификатор сеанса к URL-адресам внутри вашего php. Этот подход, однако, имеет несколько недостатков. В основном это сохранение состояния в URL, а не в заголовке Cookie. Если бы пользователь скопировал и вставил URL-адрес страницы, на которой он находился, и кто-то другой щелкнул бы по нему, они оба использовали бы один и тот же сеанс.

<?php
     ini_set("session.use_cookies", 0);
     ini_set("session.use_only_cookies", 0);
     ini_set("session.use_trans_sid", 1);
     ini_set("session.cache_limiter", "");
     session_start();
 Henrik Erlandsson08 дек. 2010 г., 21:26
«(Даже у пауков теперь могут быть печенья)» :) Я говорю, пусть они, даже если это дает им любовь ручки.
 Mike04 апр. 2012 г., 17:05
Просто к вашему сведению, на самом деле в ЕС существует законное требование запрашивать разрешение у пользователей, прежде чем хранить куки на своих компьютерах (хотя я понимаю, что, вероятно, он не вернулся, когда был опубликован оригинальный ответ)
 sleepy_keita03 мар. 2013 г., 03:14
 Your Common Sense18 сент. 2010 г., 10:33
И следует отметить, что эти настройки не изменяют гиперссылки JS и заголовки Location в коде PHP.
 w43L28 июн. 2011 г., 10:03
Приложения Facebook работают в IFrame, которому в IE не разрешено хранить куки (настройки безопасности по умолчанию)
 Martijn Heemels30 июн. 2011 г., 10:13
Похоже, вы все слепо следите за куки-файлами. Однако при использовании прокси-кэша, такого как Varnish, сессионные cookie-файлы ужасны. Они серьезно снижают кешируемость контента.
 Martijn Heemels30 июн. 2011 г., 10:23
Чтобы уточнить, обязательно используйте сеансовый файл cookie, когда вытребовать сеанс, но избегайте ненужного использования сеансов. Не начинайте сеанс по привычке. Удалите файл cookie сеанса, когда он вам больше не нужен, и не запускайте сеансы для запросов, которые не используют его, таких как изображения и таблицы стилей. Многие фреймворки по умолчанию устанавливают сеанс навсе, Избегайте такого поведения.
 erm3nda11 нояб. 2015 г., 08:40
"имеет несколько минусов" Это не совсем так, если вы используете проверку IP на каждом созданном сеансе. Если IP не является тем же сеансом уничтожения, тогда вы в безопасности. Вы сможете поделиться этим URL даже с SESSION, и никто не сможет получить ваш сеанс за пределами вашего текущего IP. Для мега чувствительных данных это было бы хорошим чтением, которое включает в себя другие вещи, которые делают сеансы более надежными и широко используемыми, предотвращая угонblog.teamtreehouse.com/how-to-create-bulletproof-sessions
 Piskvor24 сент. 2010 г., 14:03
В самом деле, кто еще просматривает файлы cookie в 2010 году? Хотя это все еще возможно, я сомневаюсь, что кто-то еще делает это; и, таким образом, вопрос довольно академический. (Даже пауки могут иметь печенье сейчас)
 Your Common Sense18 сент. 2010 г., 10:27
Я считаю, что ОП хотелsession.use_cookies установить на 1
 sleepy_keita03 мар. 2013 г., 03:14
@MartijnHeemels Вот почему вы должны разделить кэшируемый и не кэшируемый контент, и почему существует заголовок Vary :.
 William T Froggard17 дек. 2018 г., 00:49
Я склонен задаваться вопросом, на что была бы похожа жизнь, если бы HTTP-соединения не были такими эфемерными, как они. Если бы защищенное соединение поддерживалось всегда, нам не пришлось бы беспокоиться о таких вещах, как сеансовые файлы cookie и тому подобное. Даже восстановление безопасного соединения в случае сбоя - это то, что хорошо для многих протоколов. Но поскольку HTTP и HTTPS отключаются после каждого сеанса связи, мы должны беспокоиться о том, чтобы убедиться, что каждая новая попытка соединения выполняется одним и тем же человеком, который подключился в первый раз, что является гораздо более сложной задачей.

$_SERVER Vars против запроса на каждой странице загрузки. Это угроза безопасности, но с достаточным количеством переменных (посмотрите на списокВот) вы можете почувствовать, что у вас есть шанс угнать до приемлемого уровня; только вы знаете, насколько безопасным должно быть ваше приложение.

ь файлы cookie с помощью:

ini_set('session.use_cookies', 0);
ini_set('session.use_only_cookies', 0);
ini_set('session.use_trans_sid', 1);
session_start();
// IP check
if($_SESSION['ip_check'] != $_SERVER['REMOTE_ADDR']){
   session_regenerate_id();
   session_destroy();
   session_start();
}
$_SESSION['ip_check'] = $_SERVER['REMOTE_ADDR'];
// session stuff

Примечание. Не рекомендуется использовать идентификаторы сеансов в URL. IP-адреса могут меняться, когда вы путешествуете с беспроводной картой, и прокси-серверы имеют один и тот же IP-адрес. Он легко ломается при нажатии на «старый URL» (со старым идентификатором сеанса).

Вы также можете быть заинтересованы в создании собственной функции обработки сеансов (в сочетании с базой данных). Вы игнорируете идентификатор сеанса и привязываете его к IP-адресу. (см. примеры вhttp://php.net/manual/en/function.session-set-save-handler.php)

Рекомендации:

http://php.net/manual/en/session.configuration.php
 Gellweiler16 авг. 2014 г., 10:28
Здесь, в Германии, у крупнейшего интернет-провайдера (Telekom) даже есть собственный прокси, которым пользуются многие. Так что в худшем случае дырявая сеть ISP будет использовать одну учетную запись. Это действительно раздражает, так как делает практически невозможным запрет IP-адресов, если вы не хотите полагаться на заголовок X-HTTP-Forwarded-For.
 Sliq26 авг. 2013 г., 19:59
@Leander Wooord! Это может привести к очень плохим ситуациям, когда весь жилой комплекс компании / семьи / студента имеет доступ к учетной записи вашего пользователя.
 Leander30 мая 2013 г., 13:22
Привязка к IP-адресу кажется плохим способом. Некоторые (корпоративные?) Пользователи могут находиться за прокси-сервером, где несколько пользователей могут иметь один и тот же IP-адрес.

session.use_trans_sid в true, чтобы активировать добавление идентификатора сеанса к каждому URL. Посмотри наэтот.

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

переменных, кроме файла cookie, небезопасно.

Подумайте об этом: когда пользователь FIRST запрашивает страницу, сервер отправляет страницу вместе с уникальным значением, говорящим «HTTP не имеет состояния, сохраните его, чтобы я знал, что это« вы »при следующем вызове». Это означает, что этот пользователь в этом браузере (независимо от вкладки), работающий в то время, имеет уникальный токен.

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

Несколько браузеров могут использовать один и тот же IP-адрес. У нескольких людей может быть ТОЧНО один и тот же пользовательский агент. Cookie - это единственная система хранения, которая работает.

На самом деле есть еще один способ - добавить уникальный токен вкаждая ссылка обратно на сервер а также все AJAX-звонки, как?PHPSESSID=my-unique-token-189481958 - но это боль в коде.

Создайте таблицу mysql с тремя полями: session_id, ip и уникальным временным ключом (для зарегистрированных пользователей) или любым другим условием, которое вам нравится. Затем отключите сеансовые куки и используйте use_trans_sid.

затем создайте код для управления поведением сеанса на основе этой новой таблицы!

послеsession_start() сохранить session_id в таблице, а затем получить его из таблицы (по IP и любым другим условиям), а затем вызвать

session_id($in_table_session_id);

Для получения дополнительной информации и полного руководства см .:https://gist.github.com/mimrahe/77415f4a9e238c313bbe8c42f8a6b7fe

 T3026 апр. 2018 г., 18:04
Нет извините, также быстрый поиск поarchive.org не дает никакого результата ...
 dcromley26 апр. 2018 г., 17:02
@ T30 Ссылка "для получения дополнительной информации и полного руководства см." Неверна - постер "мертв". У вас есть ссылка для этого? Благодарю.
 Mike Kormendy12 окт. 2017 г., 00:52
Опять же, это привязка по IP и не совсем эффективная, особенно для областей, где несколько пользователей используют один и тот же IP (например, университет, компания или прокси-серверы организации и т. Д.)

я бы добавил идентификатор сеанса в код HTML в качестве тега комментария, а также использовал и настроил код PHP для использования идентификатора сеанса, который включен в код HTML. Я думаю, что будет более уместным сделать это вместо того, чтобы делать это с IP-адресом пользователя или добавлять идентификатор сеанса в URL.

 ebichuhamster17 сент. 2018 г., 10:31
+1 кажется большой работой, но это определенно обходные идентификаторы сессии и куки. может быть, даже более безопасным, если у вас есть случайная строка, сгенерированная для каждой формы. комбинируя случайную строку формы и скрытый идентификатор сеанса, вы почти уверены, что авторизованный пользователь делает запрос. я знаю, что Рор использует что-то вроде этого.guides.rubyonrails.org/form_helpers.html

Ваш ответ на вопрос