Есть несколько хороших вариантов OAuth на чистом PHP, о которых стоит упомянуть. Чтобы понять их хорошие и плохие части, необходимо понять, как работает OAuth. Давайте рассмотрим.
В этом примере Поставщик - Imgur, Потребитель - ваш код , а Пользователь - пользователь.
- Поставщик выдает Потребителю Ключ и Секрет Потребителя.
- Пользователь делает запрос Потребителю.
- Потребитель запрашивает у Поставщика токен запроса и Секрет запроса. Обычно они хранятся в сеансе пользователя.
- Потребитель перенаправляет пользователя к провайдеру с токеном запроса. Большинство примеров в сети теперь устанавливают состояние сеанса пользователя на «1».
- Пользователь разрешает доступ Потребителя к Провайдеру.
- Поставщик отправляет пользователя обратно к потребителю с (другим?) Токеном запроса.
- Потребитель отправляет возвращенный токен запроса и ранее отправленный секрет запроса поставщику.
- Поставщик возвращает токен доступа и секрет доступа. Обычно они хранятся в сеансе пользователя, но они могут быть долговременными и заслуживать лучшего места для долгосрочного хранения.
- Для дальнейших запросов от потребителя к провайдеру требуются ключ потребителя, секрет потребителя, токен доступа и секрет доступа.
Когда мы нажимаем шаг 9, объект OAuth в вашем коде имеет все необходимое для выполнения запросов. Ключевая, критическая часть заключается в том, что объект OAuth должен обрабатывать запросы API сам , чтобы он мог правильно подписывать данные, передаваемые по проводам.
Есть два хороших варианта на выбор, и некоторые не очень хорошие. Давайте рассмотрим хорошие:
Сначала это PEAR's HTTP_OAuth , который использует HTTP_Request2 в качестве базовой библиотеки HTTP. Хотя он работает нормально, HTTP_OAuth_Consumer_Request действует как шлюз для объекта запроса, но не наследуется от него. Это означает, что вы не можете сделать с ним все, что вы можете сделать с HTTP_Request2. Это может раздражать.
Во-вторых, есть Zend Framework Zend_Oauth , который использует Zend_Http_Client в качестве базовой библиотеки HTTP. Хотя это часть большей Zend Framework, эти два компонента в значительной степени независимы и хорошо работают с другими платформами ... или вообще без них. В отличие от библиотеки PEAR, Zend_Oauth_Consumer фактически возвращает класс, производный от Zend_Http_Client. Нельзя сказать, что это не делает его собственную странную вещь. Вместо того чтобы просить вас спрятать токен и секрет в сеансе, он хочет, чтобы вы вместо этого сериализовали объект токена статуса, который содержит токен и секрет. Он выполняет свою работу, но это просто странно.
Игнорирование бородавок, оба хороших варианта для вас. Они оба выпущены под либеральными лицензиями с открытым исходным кодом, поэтому у вас не будет проблем с их связыванием с вашим кодом. *
В не очень хорошей категории есть oauth-php . Мне было все равно, работать с библиотекой, слишком много отвлекающих факторов и мелочей, которые меня раздражали. Существует также расширение oauth PECL . Хотя он использует CURL, невозможно получить из него CURL-дескриптор, чтобы делать свои собственные вменяемые запросы. Вы также упомянули, что у вас его не установлено, поэтому он находится в не очень хорошей категории.
Что касается взаимодействия с Имгуром ... это просто ванильный JSON. Переберите родные PHP json_encode и json_decode, и у вас не возникнет никаких проблем. Документация API чертовски хороша.
* Я не юрист, вы можете проконсультироваться с одним из них.
(Части этого ответа дословно скопированы из библиотеки неполного Imgur API, которую я начал писать. К сожалению, я ничего не реализовывал в альбомах, иначе я просто связал бы ее. Однажды он сделал то, что мне было нужно, я остановился. Извините.