简体   繁体   中英

PHP OAuthProvider Returns HTTP 500

I'm working on adding OAuth to a RESTful API. Surprisingly, using PHP's OAuth and OAuthProvider classes (from pecl/oauth) I've not had any problems with signatures, etc.

Where I am encountering problems is in what happens when errors such as a bad timestamp occur. I'm setting up my provider as follows:

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.
    }
}

When all of the handler functions return OAUTH_OK , the request is able to proceed as expected. To see what happens when the timestamp is bad, I've written my timestampNonceHandler like this:

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

When I run this, passing a correctly signed request (yes, I'm sure), the response is an 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

The message is right, but surely this should be an HTTP 401.

Am I doing something wrong here, or does OAuthProvider just treat any failure as an Internal Server Error?

Thanks in advance for your help.

The draft of OAuth describes the use of 400 and 401 headers in a simple way.

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

The actual OAuth protocol at http://tools.ietf.org/html/rfc5849 speaketh thus:

If the request fails verification, the server SHOULD respond with the appropriate HTTP response status code. The server MAY include
further details about why the request was rejected in the response
body.

The server SHOULD return a 400 (Bad Request) status code when
receiving a request with unsupported parameters, an unsupported
signature method, missing parameters, or duplicated protocol
parameters. The server SHOULD return a 401 (Unauthorized) status
code when receiving a request with invalid client credentials, an
invalid or expired token, an invalid signature, or an invalid or used nonce .

And the word "SHOULD", as defined in http://tools.ietf.org/html/rfc2119

  1. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

While I dont have a definitive answer, I guess that the authors are gratuitously using the 500 code without considering the "full implications" , unless the library hits an actual error each time there is an "outdated" request. But it seems perfectly valid.

What happens if you add a $provider->reportProblem() inside of the catch?

The problem reporting extension is exposed via OAuthProvider::reportProblem()

If you don't see the expected behavior can you provide the pkg version? I'll file a bug and have it fixed ASAP.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM