PHP-сессии и уникальные пользовательские токены

Я пытаюсь реализовать что-то вроде OAuth в PHP, и я хочу дать пользователям токены, чтобы они могли использовать свои личные ресурсы. Каждый пользователь сначала должен войти в систему со своим адресом электронной почты и паролем и получить уникальный токен, который будет действовать вечно, если только он не будет бездействовать в течение "n" минут. Поэтому, если в течение «n» минут нет запросов, токен должен быть уничтожен. Токен будет использоваться для доступа пользователей к частным ресурсам.

Одна вещь, которую я могу придумать, это как...

Я бы поддерживал таблицу БД с именем user_tokens, и когда они входят в систему со своим именем пользователя и паролем, там будет создана запись с уникальным токеном. Будет установлена ​​метка времени последнего доступа, и пользователю будет предоставлен уникальный токен в качестве ответа. Токен теперь можно использовать для доступа к личным ресурсам пользователя, и он должен будет проходить со всеми запросами, требующими токена. Каждый частный запрос будет проверять, имеет ли последняя временная метка и текущая временная метка разницу в «n» минут, если да, уничтожить токен. В противном случае отправьте ответ с запрошенными ресурсами и установите последнюю временную метку на текущую временную метку.

Имеет ли это смысл? Или может быть другой эффективный способ сделать это?

Я хотел бы добавить, что токен должен быть похож на то, что твиттер или фейсбук возвращает из своего API.


php oauth http-authentication
person Umair A.    schedule 15.12.2011    source источник
comment
Почему вы пытаетесь изобретать велосипед и где OAuth вам не подходит?   -  person Grad van Horck    schedule 15.12.2011
comment
Я никогда не использовал OAuth, но только что прочитал об этом. Это единственная причина. Я хочу, чтобы это было сделано в ближайшее время с уже известными концепциями, которые у меня есть.   -  person Umair A.    schedule 15.12.2011
comment
Я бы действительно пошел на реализацию библиотеки php oauth (например, php-oauth или расширения PHP). При работе с безопасностью рекомендуется использовать существующие, хорошо продуманные стандарты, а не внедрять собственные. Вероятность того, что вы сделаете небольшую криптографическую ошибку, намного выше, чем при использовании проверенного стандарта. Кроме того, в качестве бонуса написание клиентов стало проще, вы также можете повторно использовать клиенты OAuth, а другим разработчикам не нужна специальная документация для взаимодействия с вашим сервисом.   -  person Grad van Horck    schedule 15.12.2011
comment
Еще одно отличие, которое я вижу. Пользователь должен передать адрес электронной почты и пароль API для получения токена. В OAuth он перенаправляет пользователя на страницу веб-сайта, где они его запрашивают, и перенаправляет обратно на returnURL. правильно?   -  person Umair A.    schedule 15.12.2011
comment
Все перенаправление в потоке OAuth является необязательным и используется для улучшения взаимодействия с пользователем (см. такие приложения, как Twitter). Нет никаких причин, по которым вы не можете отображать access_token пользователя при просмотре страницы его профиля на вашем веб-сайте. (На самом деле, это также то, что делает твиттер, когда вы просматриваете одно из своих приложений на панели инструментов разработчика).   -  person Grad van Horck    schedule 15.12.2011
comment
Какой OAuth API для PHP вы предпочитаете, быстрый в освоении, простой в реализации и максимально безопасный?   -  person Umair A.    schedule 15.12.2011

Ответы (2)


arrow_upward
0
arrow_downward

Если вы хотите реализовать OAuth с помощью библиотеки, вам следует ознакомиться с pear-пакетом HTTP_OAuth от Джеффа Ходсона из Digg[1], и на этом сайте есть множество хороших статей о проектировании баз данных для использования с Oauth[2].

Я думаю, что я смущен вашим вопросом, хотя. Вы хотите создать API для своего веб-приложения или просто предоставить способ защитить ресурсы пользователя? Если вы хотите создать API, вам обязательно следует использовать OAuth, а также использовать известную библиотеку. Это гарантирует, что:

  1. Другие разработчики узнают, как использовать ваш API, поскольку он соответствует OAuth RFC[3].
  2. Ваше веб-приложение с гораздо большей вероятностью будет безопасным
  3. Вы узнаете о лучших практиках и узнаете что-то новое

Если вы не хотите создавать API, а просто хотите защитить пользовательские ресурсы, я думаю, вы будете в безопасности, используя сеансы [4], и, если пользователь не вошел в систему, он не может получить доступ к защищенным ресурсам.

[1] Пакет HTTP_OAuth: http://pear.php.net/pepr/pepr-proposal-show.php?id=607
[2] Дизайн базы данных Oauth: Какова рекомендуемая структура базы данных для поставщика OAuth
[3] Oauth RFC: http://oauth.net/
[4] Сессии PHP: http://us2.php.net/manual/en/features.sessions.php

person Steve    schedule 16.12.2011
comment
что, если я решу, что должен реализовать OAuth, но без библиотеки? - person Umair A.; 16.12.2011
comment
Если у вас достаточно времени и вы действительно хотите изучить тонкости спецификации, то я говорю, дерзайте! Однако на это, скорее всего, уйдет очень много времени из-за того, насколько подробно описана спецификация с рабочим процессом, созданием подписей и обработкой запросов. Вы всегда можете использовать библиотеку в качестве эталона, но также примите во внимание, что библиотека уже использовалась кучей людей, поэтому она действительно стабильна. - person Steve; 16.12.2011

arrow_upward
0
arrow_downward

Я использую session_regenerate_id для генерации токена, до того, как я использовал session_id, но я понял, что при использовании session_id sessID никогда не меняет значение, а затем его повторное создание было решением, которое мне подходит.

Теперь я даже могу контролировать, есть ли один и тот же пользователь, но с другим sessID, и дать возможность выйти из сеансов одного пользователя.

Я не знаю, именно то, что вы ищете, но это решает мою проблему с TOKEN. И это никогда не повторится.

Ссылка: https://www.php.net/manual/en/function.session-regenerate-id.php

person devasia2112    schedule 15.12.2011