OAuth to Elgg site

56 views
Skip to first unread message

dterango

unread,
Feb 17, 2012, 3:52:04 PM2/17/12
to Signpost users
Hi all,

Gonna share a conversation with Matthias around an issue found trying
to OAuth against en Elgg site.

Me:
-----------------------------
I'm trying to authenticate an android app against an OAuth 1.0a
Provider. During third step, retrieving Access Token, server sends
back a 'HTTP 500 Internal Server Error' cause Consumer doesn't include
'oauth_verifier' in the request. So, it seems Consumer doesn't detect
properly 1.0a version during Request Token dialogue. What attributes
are needed for the Consumer to detect 1.0a in order for me to ask the
API developer for a bug?

As workaround, I'm trying to insert the argument into Access Token
request with something like:

HttpParameters params = new HttpParameters();
params.put("oauth_verifier", verifier);
provider.retrieveAccessToken(consumer, verifier);

without success. I don't know is this is the way cause it's difficult
for me to guess from javadoc.

Thank in advance !!!

P.S.: Registering the App as version 1.0 works perfectly because
'oauth_verifier' isn't expected, obviously :)
-----------------------------

Matthias:
-----------------------------
I know that's not a very satisfying answer, but it's probably the
service provider that's buggy. I have tested the library with lots of
1.0a providers and they all worked. 1.0a capability of the server is
detected using auto-sensing: whenever you DON'T send the callback URL
as part of the authorization URL (that's a 1.0 only thing), but as
part of the request token request, the server must send a response
parameter called oauth_callback_confirmed. If that is missing or
malformed, 1.0a detection will break, Signpost will think it's a 1.0
server, and thus even if you provide a verifier in the access token
step, it will not be sent to the server.

My suggestion:

1) inspect the payload of the request token server response, and check
whether oauth_callback_confirmed is set.

2) If not, before requesting the access token, set the provider to
1.0a manually like so:

oauthProvider.setOAuth1.0a(true);
oauthProvider.retrieveAccessToken(...);

that way you don't have to rely on auto sensing to work during the
request token step. If that still doesn't work, then there is not much
you can do apart from filing a bug against their OAuth API ;-)
-----------------------------

Me again:
-----------------------------
I checked Request Token response for provider and
oauth_callback_confirmed isn't included, as you guess. Forcing to 1.0a
doesn't seem to work for me. So I'm going to forward this issue to
OAuth API Developer in order to fix it.
-----------------------------


That's all. Any comment will be helpful !!

Takahiro Horikawa

unread,
Feb 25, 2012, 12:12:37 PM2/25/12
to signpos...@googlegroups.com
Hi,

I've checked source code, and I still think "setOAuth1.0a(true);" might solve your problem.
Could you confirm you call "OAuthProvider.setOAuth1.0a(true);" right before "OauthProvider.retrieveAccessToken(...);"?
Please note that "isOAuth10a" is automatically modified to "false" after calling "OauthProvider.retrieveRequestToken(...);".

Regards,
Takahiro Horikawa

dterango

unread,
Mar 12, 2012, 1:13:37 PM3/12/12
to Signpost users
Hi,

Don't worry, I talked to plugin developer and he adapted api code to
specification. Now it works!

Thanks.

On 25 feb, 18:12, Takahiro Horikawa <horikawa.takah...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages