SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Clarify OAuth Authentication Cycle

    Hello,

    I am trying to familiarize myself with OAuth API authentication process

    I was successful in getting API access token but I am struggling to understand how to make signed requests

    PRIMER:

    To implement the OAuth from my server I used the library http://code.google.com/p/oauth-php/

    I got the consumer API key and the consumer API secret from the service provider

    After much trial and error, I was able to

    1) request get Request Token

    2) then the user (myself in this case) was redirected to service provider

    3) after the user granted access to consumer, service provider redirected user to consumer's "callback" url

    4) then I exchanged the request token for an access token, the results I get include an access token and a token secret

    AND THEN I UNDERSTAND I should be able to make "signed requests"

    from the library I used, I do this by calling two methods,

    a) create a new OAuth object (from documentation "obtain a request object for the request we want to make")
    and
    b) OAuthobject->doRequest ("sign the request, perform curl request and return results...")

    Making signed requests is where I am confused.

    Do I need to get an access token every time I try to access a protected resource?

    I imagine not, but the API I accessed required "signed OAuth headers" for CERTAIN resrouces. In ohter words, I would go through the whole process once, and I would be able to access some images WITHOUT going through the getting request token and getting access token part. But to access these other resources, the ones that indicated consumer needed "signed OAuth headers" to make requests, I would have to go through the whole process, get request token, exschange request-access token, and then I could retrieve these.

    I imagine that perhaps I am doing extra work, and I do not need to get the request token nor exchange the request-access token, since it is store in my database, and I suspect there must be a live term data associated with it. But since I don;t know I am having to go through the whole cycle.

    How would I make correct "signed request" w/o having the user authorize access and then getting a new access token?

    I hope that I wrote above gives you an idea of how I view the OAth model. I would like a reader to help me get a clear idea of how the cycle goes? How can I retireve the resources w/o having to get user authorization every time.

    Thank you

    For those landing in this post looking to understand OAuth process, you can look at this image "OAuth Authentication Flow": http://oauth.net/core/diagram.png

  2. #2
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would like to be more specific about this part.

    Quote Originally Posted by websonalized View Post
    ...to make "signed requests"

    from the library I used, I do this by calling two methods,

    a) create a new OAuth object (from documentation "obtain a request object for the request we want to make")
    and
    b) OAuthobject->doRequest ("sign the request, perform curl request and return results...")

    Making signed requests is where I am confused.

    Do I need to get an[CORRECTION a new] access token every time I try to access a protected resource? ...
    In short, after I had gotten the access token and secret pair, some resources were accessible by creating a new OAuth object and then calling method doRequest.

    But resources that where labeled "required signed OAuth headers" I had to go through the whole cycle ( here is where I fear b/c I do not know better), and so I get request token, sned to service provider, get user authorization, exchange request-access token, then make signed request.

    SO, why are the new Object and the doRequest method, or as documentation indicates calling the signed request, not enough for resources labeled "required signed OAuth headers"

    How is it the request of OAuth headers different than having the old access token and making a simple signed request?

    THANK YOU

  3. #3
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lightbulb

    OK, so I figured my answer.

    Once I have the access token, I use this until it expires, or until it is revoked by the user.

    My confusion stemed from the fact that in the example provided by the library's wiki, I was able to make a signed request w/o having to explicitly insert the oauth_token into the request url

    For clarity: http://code.google.com/p/oauth-php/w...Signed_Request

    And I was imitatingthe steps w/o success.

    As I reviewed the code, I saw no easy way to access the access token from the database, unless I hardcoded a database call, and I wanted to avoid this.

    But after hours and trying this class and that function, I landed on function getNormalizedParams() from class OAuthRequester

    And so here it is how to make signed requests after we have our access token into the database (reminder, this is using the oauth-php library):


    Code:
    <?php
    
    include_once "../../library/OAuthStore.php";
    include_once "../../library/OAuthRequester.php";
    
    $request_uri = "http://www.theserviceprovider.com/api/some_protected_resource_or_another"; 
    
    $dboptions = array('server' => 'localhost', 'username' => 'user_db',
                    'password' => 'pwd_db',  'database' => 'oauth');
    	
    $store   = OAuthStore::instance('MySQL', $dboptions);
    $method = "POST";
    $params = null;
    
    try
    {
    	
    	$request = new OAuthRequester($request_uri, $method, $params);
    	
    	$result = $request->doRequest(1, $request -> getNormalizedParams());
    
    	echo "RESULT :<pre>";
    	print_r($result);
    	echo "</pre>";
    }
    catch(OAuthException2 $e)
    {
    		echo "EXCEPTION :<pre>";
    		print_r($e);
    		echo "</pre>";	
    }
    
    ?>
    The difference in this request, vs. the one in the example shown in the library's wiki, is the explicit insertion of the token_auth (lettering in bold)

    For better understanding, compare the example linked above and this request.

    It worked for me.

    P.S. there is this really cool sandbox that helps us visualize the process (written for google API in particular): http://googlecodesamples.com/oauth_playground/index.php
    Last edited by websonalized; Apr 6, 2012 at 23:36. Reason: clarity in code

  4. #4
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    CORRECTION!!!

    I am sorry, no need for extra nothing. I don't know why copying the example did not work for me (two days), but now it does, without adding any extras to the original example code

    FOR SINGED REQUESTS AFTER YOU HAVE ACCESS TOKEN

    [QUOTE=websonalized;5097936]


    Code:
    <?php
    
    include_once "../../library/OAuthStore.php";
    include_once "../../library/OAuthRequester.php";
    
    $request_uri = "http://www.theserviceprovider.com/api/some_protected_resource_or_another"; 
    
    $dboptions = array('server' => 'localhost', 'username' => 'user_db',
                    'password' => 'pwd_db',  'database' => 'oauth');
    	
    $store   = OAuthStore::instance('MySQL', $dboptions);
    $method = "POST";
    $params = null;
    
    try
    {
    	
    	$request = new OAuthRequester($request_uri, $method, $params);
    	
    	$result = $request->doRequest(1);
    
    	echo "RESULT :<pre>";
    	print_r($result);
    	echo "</pre>";
    }
    catch(OAuthException2 $e)
    {
    		echo "EXCEPTION :<pre>";
    		print_r($e);
    		echo "</pre>";	
    }
    
    ?>
    the 1 in $result = $request->doRequest(1) corresponds to $usr_id, I am using the same user to it is static here


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •