Веб-сессия или сеанс без связи

Question

Я собираюсь создать таблицу сеанса, содержащую случайный #, идентификатор пользователя, дату/время, который заполняется при входе пользователя в систему, а случайный #, используемый на каждой отображаемой странице, для однозначной идентификации персона. Каждый раз, когда пользователь отображает страницу, запись будет обновляться с самой последней активностью даты/времени, если в прошлые х часов не было никакой активности, чем я планирую вызывать повторный вход. Пара вопросов:

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

Есть ли лучший подход или стандартный шаблон безопасности, который есть (и я не знаю)?

Answer 1

Пункт 1 - Зависит, если люди на

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

Пункт 3 - Один или другой должен быть адекватным.

Answer 2

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

2. Я бы предложил использовать сеансовый подход, потому что обычно это 20-минутный тайм-аут, если он не изменен администратором сервера.

Answer 3

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

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

Вся цель сеанса - хранить значения, относящиеся к этому человеку на этом компьютере, что именно то, что вы ищете. Дублирование кажется излишним.

Answer 4

Почему бы не просто использовать сеанс PHP по умолчанию и не хранить его в базе данных?
Существует несколько функций, позволяющих вам переопределить, что делает PHP, когда сеанс доступен или обновлен.

This article объясняет это.

Answer 5

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

Answer 6

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

В общем, я предпочитаю использовать файлы cookie, потому что пользователи могут оставаться в системе между сеансами (т. Е. Когда они закрывают браузер и возвращаются).

Answer 7

1. Используйте файлы cookie для заполнения сеанса.
2. Используйте сеанс для вашего обычного использования.
3. Обязательно наличие случайной строки, хранящейся через db за сеанс.
4. Сохраните IP-адреса в db только для вашей собственной информации, если вам нужно сделать временный запрет IP, но не используйте их, как они непогрешимы.

Answer 8

Зачем вам нужна база данных для сеансов треков. Разве вы не думаете, что это накладные расходы? Я бы предложил вам продолжить сеансы PHP.

Answer 9

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

Answer 10

Ответ на этот вопрос И то и другое!

Главное: Вы должны никогда не слепо принимать куки или сессии для проверки пользователей, оба из которых легко похищенные XSS, и могут быть использованы злоумышленниками, кроме происхождения.

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

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

Это может использоваться для одновременного входа в систему двух отдельных браузеров для одного идентификатора пользователя, который не может быть выполнен только с сеансов с сеансов неважно, кто их создал или когда. Но с checkin-checkout, так как уникальный идентификатор всегда отличается, произойдет несоответствие.

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

Так Login-> Создать сеанс/Validation- пользователя> Далее PAGE-> Validate сеанс с базой данных Unique ID + Validate user-> Generate New Session Unique id-> Обновление пользователя Последний On/Unique ID

В в конце он может дать вам лучший обзор того, где ваши пользователи обращаются к своим учетным записям, и как часто из каждой точки EG: работать x 3, home x 5, mobile x 1. И также позволяет вам защищать своих пользователей от краж аккаунтов. EG: Немецкий пользователь внезапно входит в систему из Таиланда или США. Сообщите им об изменении и отправьте запрос, чтобы проверить изменение на их электронную почту.