No User ID Returned with 2-Legged OAuth

[GoogleCodeExporter]

This might be my misunderstanding of the OAuth specs and of the library,
but if I use 2-legged oauth to generate headers, the $token_type should be
FALSE.

In OAuthStoreSQL.php Line 119, if $token_type is FALSE, then it does not
return the ost_usa_id_ref as user_id, like it does for other $token_types.

If each user is given a unique consumer_key and consumer_secret, is there
reason I cannot identify the a user using 2-legged oauth? 

Original issue reported on code.google.com by timtrini...@gmail.com on 25 May 2010 at 12:35

[GoogleCodeExporter]

I think not. If you are using 2-legged oauth you may not be associating your 
user
with a local user. You may do that, but it's not what the protocol suggests -- 
since
you'll have to store the remote user and password. If you are using the local 
user
and password, I think you already have the identification, right? 

If I misunderstood your question, please let me know. I'll leave this open 
until we
find out if we are speaking about the same thing.

Original comment by brunobg%...@gtempaccount.com on 26 May 2010 at 7:27

[GoogleCodeExporter]

Original comment by brunobg%...@gtempaccount.com on 26 May 2010 at 7:45

• Changed state: Discussion

[GoogleCodeExporter]

I'm not sure - here's what I am trying to do:

Each user is given a consumer_key and consumer_secret. When they access the site
using the appropriate OAuth header, I need to be able to identify the user by
consumer key.  In essence, each consumer is tied to a site user. There is no 
remote
username or password since the only system is ours.  Requests without the OAuth
header will be treated as anonymous requests.

Eventually, we are also going to support three-legged oauth for third party apps
acting on behalf of users, but it's unnecessary for now.

Original comment by timtrini...@gmail.com on 26 May 2010 at 7:55

[GoogleCodeExporter]

Ok, I think I get what you mean. First of all, I'm not sure why there is a 
token type
FALSE. I didn't write that code and the oauth spec mentions only "access" and
"request", so it seems just a hack to override it in and generate the headers, 
as you
say, if you don't have 'oauth_token'. I'm not sure why you need to do that, to 
be
frank...

Given that, the oauth_server_token table is not accessed when token_type is 
false. My
guess is that it's a security measure, because $token is ignored (since you 
don't
have 'oauth_token'). The special case is written so deliberately that it must 
have
been for a good reason, and since I'm not sure, I'd rather not just remove it. 

You could call getConsumer to get that information, if you are admin. If you do 
have
'oauth_token', then just set token_type as "access" -- it does not seem to have 
any
side effects and I think it will work. 

Let me know if this solves your problem.

Original comment by brunobg%...@gtempaccount.com on 26 May 2010 at 8:48

[GoogleCodeExporter]

I think that works! This is what I ended up with - does this look about right?:

  if (OAuthRequestVerifier::requestIsSigned()){
    try{ 
      $req = new OAuthRequestVerifier();
      $req->verify(FALSE);
      // If no errors were thrown, the request checks out
      $consumer_key = $req->getParam('oauth_consumer_key');
      $store = OAuthStore::instance();
      $consumer = $store->getConsumer($consumer_key, NULL, TRUE);
      $user_id = $consumer['user_id'];
      // Do authenticated stuff
    }
    catch (OAuthException2 $e){
      // The request was signed, but failed verification
      header('HTTP/1.1 401 Unauthorized');
      header('WWW-Authenticate: OAuth realm=""');
      header('Content-Type: text/plain; charset=utf8');
      exit();
    }
  } else {
    // Do anonymous stuff
  }

Original comment by timtrini...@gmail.com on 27 May 2010 at 2:19

[GoogleCodeExporter]

Yes, that is precisely it :) 

Original comment by brunobg%...@gtempaccount.com on 27 May 2010 at 4:46

• Changed state: Fixed