Как лучше всего использовать куки для аутентификации с помощью PHP? - PullRequest
6 голосов
/ 28 октября 2009

Я ищу советы и идеи о том, как наилучшим образом включить аутентификацию в PHP с использованием файлов cookie.

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

Как: blahblahblah.com/ и blahblahblah.com/login/

Могут ли они оба прочитать печенье?

Множество вопросов на один пост, но спасибо!

Ответы [ 4 ]

3 голосов
/ 28 октября 2009

на стороне клиента нет ничего безопасного.

Вы легко меняете флаг входа в Cookies в любом браузере. Поэтому рекомендуется сохранять данные, связанные с входом в систему, на $ _SESSION

php.

Если вы хотите продлить сеанс, просто посмотрите на session_set_cookie_params().

По умолчанию один и тот же сеанс будет использоваться для текущего домена и всех путей в этом домене. Таким образом, он доступен для чтения как для blahblahblah.com/, так и для blahblahblah.com/login/

Когда пользователь входит в систему, сохраните имя пользователя и хэш пароля в сеансе.

В начале каждого сценария проверьте имя пользователя и пароль сеанса с тем, который указан в базе данных. Если все верно, тогда установите флаг (например, $ userLoggedIn = true), чтобы указать на стороне сервера, что пользователь вошел в систему. Иначе false.

2 голосов
/ 28 октября 2009

Некоторые мысли, без определенного порядка:

  • Разделите различные уровни: постоянное хранилище против аутентификации.
  • Сеансы PHP довольно надежны и являются рекомендуемым способом поддержания постоянного хранилища.
  • Вы можете иметь действительный сеанс, но не действительный логин.
  • Избегайте нескольких файлов cookie. Одного достаточно. PHP сессии работают с одним cookie.
  • Вы можете устанавливать субдомены и пути к файлам cookie, но на самом деле мало смысла, если вы не устанавливаете лоты, что не рекомендуется (см. Выше).
  • Вместо этого поместите все, что вы, возможно, захотите, в файл cookie в сессии.
  • У вас должен быть общий код, который включают все ваши страницы. Здесь вы инициализируете сеанс. Тогда все будет просто работать. Он также может проверить, что логин также действителен.
  • Есть одно место, которое выполняет аутентификацию при входе в систему и все, что с этим связано.
  • Не забудьте выйти из экрана выхода!
0 голосов
/ 28 октября 2009

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

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

Как сказал Маурис , на стороне клиента нет ничего безопасного - не используйте cookie для хранения значения "logged_in", которое вы проверяете на true / false!

0 голосов
/ 28 октября 2009

Рекомендуется, чтобы один скрипт выполнял проверку сеанса / входа в систему и включал его в защищенные страницы. Что касается глубины, вы можете определить это в setcookie (), если для параметра каталога установлено значение «/», то он доступен для всех.

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

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