PHP OAuthProvider возвращает HTTP 500 - PullRequest
0 голосов
/ 14 сентября 2011

Я работаю над добавлением OAuth в RESTful API.Удивительно, но с использованием PHP OAuth и OAuthProvider классов (из pecl / oauth) у меня не было проблем с подписями и т. Д.

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

public function authenticate(){
    try {
        $provider = new OAuthProvider();
        $provider->consumerHandler(array($this,'handleConsumer'));
        $provider->timestampNonceHandler(array($this,'handleTimestampNonce'));
        $provider->tokenHandler(array($this,'handleToken'));
        $provider->isRequestTokenEndpoint(FALSE);
        $provider->checkOAuthRequest();
    } catch (Exception $e) {
        // Do nothing.
    }
}

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

public function handleTimestampNonce($provider){
    return OAUTH_BAD_TIMESTAMP;
}

Когда я запускаю это, пропуская правильно подписанный запрос (да, я уверен), ответHTTP 500.

[headers_recv] => HTTP/1.1 500 Internal Server Error
Date: Wed, 14 Sep 2011 08:47:59 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8r DAV/2 PHP/5.3.4
X-Powered-By: PHP/5.3.4
Content-Length: 648
Connection: close
Content-Type: 0
[body_recv] => Invalid nonce/timestamp combination

Сообщение верное, но, несомненно, это должно быть HTTP 401.

Я что-то здесь не так делаю или OAuthProvider просто рассматривать любую ошибку как внутреннюю ошибку сервера?

Заранее спасибо за помощь.

Ответы [ 2 ]

1 голос
/ 15 сентября 2011

Что произойдет, если вы добавите $ provider-> reportProblem () внутри улова?

Расширение сообщения о проблемах предоставляется через OAuthProvider :: reportProblem ()

Если вы не видите ожидаемого поведения, можете ли вы предоставить версию pkg? Я сообщу об ошибке и исправлю ее как можно скорее.

1 голос
/ 14 сентября 2011

Проект OAuth описывает использование заголовков 400 и 401 простым способом.

http://oauth.net/core/1.0a/#http_codes

Фактический протокол OAuth при http://tools.ietf.org/html/rfc5849 говорит так:

Если запрос не прошел проверку, сервер ДОЛЖЕН ответить соответствующим кодом статуса ответа HTTP.Сервер МОЖЕТ включать
дополнительные сведения о том, почему запрос был отклонен в теле ответа
.

Сервер ДОЛЖЕН вернуть код состояния 400 (неверный запрос), когда
получает запрос с неподдерживаемымпараметры, неподдерживаемый
метод подписи, отсутствующие параметры или дублированный протокол
параметры.Серверу СЛЕДУЕТ возвращать код состояния 401 (Неавторизованный)
при получении запроса с недействительными учетными данными клиента, токеном
недействительным или просроченным, недопустимой подписью или неверным или использованным nonce .

И слово "СЛЕДУЕТ", как определено в http://tools.ietf.org/html/rfc2119

  1. СЛЕДУЕТ Это слово или прилагательное "РЕКОМЕНДУЕТСЯ",Это означает, что могут существовать веские причины в определенных обстоятельствах игнорировать
    конкретный элемент, но полное значение необходимо понять и тщательно взвесить
    , прежде чем выбрать другой курс.

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

...