Acessing request contents in oauth plugin

[sethfuller]

I am trying to get the Oauth plugin working to communicate with Context.IO. I have a Java client using the scribe library, HMAC-SHA1, and Oauth 1.0a that works. When I communicate via the Oauth plugin sending the same URL I am getting a 401 HTTP error with the text 105 Invalid signature. The tech support from Context.IO would like to see what I am sending them. Is there a way to turn on logging of the full content of the request?

[antony]

Hi There,

I'm the author of the Grails oauth-scribe Plugin. I've literally just
released a new version of the plugin which fixes a few small issues
with some Oauth 2.0 APIs.

I'll enable the new Scribe 1.3.0 debugging support and release a new
version right now - check the grails plugin portal for version 1.2 in
a few hours time which should do what you need.

Cheers,
Antony

On 23 December 2011 14:39, sethfuller <[hidden email]> wrote:

> I am trying to get the Oauth plugin working to communicate with Context.IO. I
> have a Java client using the scribe library, HMAC-SHA1, and Oauth 1.0a that
> works. When I communicate via the Oauth plugin sending the same URL I am
> getting a 401 HTTP error with the text 105 Invalid signature. The tech
> support from Context.IO would like to see what I am sending them. Is there a
> way to turn on logging of the full content of the request?
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Acessing-request-contents-in-oauth-plugin-tp4228813p4228813.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[antony]

Hi,

You can now enable debugging support in version 1.2 of the Grails
oauth-scribe plugin by adding:

debug = true

into your oauth { } closure in Config.groovy.

You should see details of the data being sent in System.out.

For information on what debugging you will see, check
https://github.com/fernandezpablo85/scribe-java/wiki/debug-mode

Cheers,
Antony

On 28 December 2011 18:31, Antony Jones <[hidden email]> wrote:

> Hi There,
>
> I'm the author of the Grails oauth-scribe Plugin. I've literally just
> released a new version of the plugin which fixes a few small issues
> with some Oauth 2.0 APIs.
>
> I'll enable the new Scribe 1.3.0 debugging support and release a new
> version right now - check the grails plugin portal for version 1.2 in
> a few hours time which should do what you need.
>
> Cheers,
> Antony
>
> On 23 December 2011 14:39, sethfuller <[hidden email]> wrote:
>> I am trying to get the Oauth plugin working to communicate with Context.IO. I
>> have a Java client using the scribe library, HMAC-SHA1, and Oauth 1.0a that
>> works. When I communicate via the Oauth plugin sending the same URL I am
>> getting a 401 HTTP error with the text 105 Invalid signature. The tech
>> support from Context.IO would like to see what I am sending them. Is there a
>> way to turn on logging of the full content of the request?
>>
>> --
>> View this message in context: http://grails.1312388.n4.nabble.com/Acessing-request-contents-in-oauth-plugin-tp4228813p4228813.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> ________________________________
> ꜽ . antony jones . http://www.enzy.org

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sethfuller]

Thanks for your reply. I found out what the problem is. We were sending the oauth_token header and they use two-legged Oauth so they didn't want that. We are using the other oauth plugin and I got around this problem by creating a new class that extends there OauthService class and overriding the sign method so it doesn't set the token.

I like the Scribe library, but we already use the other. By the way it seems that there is only provision to talk to one Oauth service in your plugin, since it doesn't let you specify providers in the Config.groovy like the other plugin does. Is that true?

[Antony Jones]

Hi Seth,

> We are using the other oauth plugin and I got around this problem by
> creating a new class that extends there OauthService class and overriding
> the sign method so it doesn't set the token.

Yeah - I used to contribute to that plugin too, but it doesn't have
any tests, and the OAuth library it uses has been abandoned for 3
years now so I decided to rewrite from scratch using something more
modern. If there is a problem with it though I don't mind fixing it -
if you can send me a patch or similar I'd be happy to get it merged
in, as there are a few other changes I'd like to make for its final
release.

> I like the Scribe library, but we already use the other. By the way it seems
> that there is only provision to talk to one Oauth service in your plugin,
> since it doesn't let you specify providers in the Config.groovy like the
> other plugin does. Is that true?

You're absolutely right, it is single-provider at the moment. I do
want to make it multi-provider as I see that this is a feature a lot
of people need, but haven't done so due to time constraints at the
moment.

It should be very easy to migrate from oauth to oauth-scribe, since
that was the basis on which I wrote the oauth-scribe plugin (and
migrated my own application). I was struggling with the oauth plugin
and committing a bunch of fixes when I reached a blocker and decided
on the rewrite. If you need multiple providers though, then yeah you
might have to wait until I get a chance to do that (or fork it and
submit a pull request ;))

Cheers,
Antony

On 28 December 2011 20:22, sethfuller <[hidden email]> wrote:

> Thanks for your reply. I found out what the problem is. We were sending the
> oauth_token header and they use two-legged Oauth so they didn't want that.
> We are using the other oauth plugin and I got around this problem by
> creating a new class that extends there OauthService class and overriding
> the sign method so it doesn't set the token.
>
> I like the Scribe library, but we already use the other. By the way it seems
> that there is only provision to talk to one Oauth service in your plugin,
> since it doesn't let you specify providers in the Config.groovy like the
> other plugin does. Is that true?
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Acessing-request-contents-in-oauth-plugin-tp4228813p4240897.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sethfuller]

All I did was remove the line like this (from the sign method):
            consumer.setTokenWithSecret(accessToken.key, accessToken.secret)

Probably a better way to handle this would be add a configuration option such as sendToken = false to the oauth configuration clause.

I like the ServiceBuilder class in the Scribe. It would be nice to either expose this in your oauth scribe plugin or add a method that you would pass a Map of options that could be set by the builder and then finally create a scribe OAuthService instance. Something like:

void configBuild(Map config) {
ServiceBuilder sb;

if (config['key']) {
  sb = sb.apiKey(config['key']);
}
if (config['secret']) {
 sb = sb.apiSecret(config['secret']);
}

... (Any other configurable options) - including a way to lookup the provider even passing an instance of the class like:

if (config['provider']) {
  sb = sb.provider(config['provider']);
}

... Finally

service = sb.build();
}

Though I can understand the idea behind setting up the configuration in Config.groovy it is limiting (it probably shouldn't go away, but this would be a nice addition).

I could even provide an implementation of this if you like. I think I have it right about how an instance of the ServiceBuilder class could be used, but I would have to try it out.

[sethfuller]

I didn't initialize the ServiceBuilder class in my example. I don't know if it has only a private constructor, but if so then perhaps config['key'] and config['secret'] could be required options and an exception could be thrown if they don't exist.

[sethfuller]

I downloaded your code and see that you have a private method called buildService which does exactly what I describe. Maybe it would be too messy to expose it to the user, but I would probably use it.

[Antony Jones]

> I downloaded your code and see that you have a private method called> buildService which does exactly what I describe. Maybe it would be too messy> to expose it to the user, but I would probably use it.

Yeah, I try to encapsulate the ServiceBuilder and sanitise a lot of
the things that are passed to it.

I see what you mean by exposing it to provide more control, but I'm
trying to make the plugin as grails-like, and
convention-over-configuration based as it can be - a-la
Groovy/Grails/G*

In all honesty, if you need the granularity of control that
ServiceBuilder grants you, then you might as well declare scribe as a
dependency of your application and use it directly. The plugin doesn't
provide much to an implementer other than that dependency and a bunch
of pre-written handling and parsing which are appropriate to a web
application.

Cheers for the code change - out of interest, what defines whether you
send a token or not? Is it just a weird OAuth implementation? I'd like
to add it to configuration but it'd be better for the end user if they
could just say in the config that it is oauth 1.0a or 2.0 and
decisions on whether to send the token would be based upon that.

Cheers,
Antony

On 29 December 2011 16:19, sethfuller <[hidden email]> wrote:

> I downloaded your code and see that you have a private method called
> buildService which does exactly what I describe. Maybe it would be too messy
> to expose it to the user, but I would probably use it.
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Acessing-request-contents-in-oauth-plugin-tp4228813p4243266.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sethfuller]

I see your point about the convention over configuration. I'll tell the lead developer about signpost being abandoned and maybe we'll go with scribe. We have two providers now and may add more so we might go with scribe directly.

The reason Context.IO doesn't want the token is they are using two-legged oauth as opposed to three-legged oauth which does seem to require the token. The oauth_token has the same value as the oauth_consumer_key so it seems redundant anyway. I am new to oauth myself so I don't know all of the nuances of what is needed. I read the tutorial on oauth that is referred to at the oauth.net site.

[Antony Jones]

> We have two providers now and may add more so we might go with scribe directly.
That sounds reasonable. I can't commit to a hard date for getting
multiple providers done in the plugin, but any future migration from
the dependency to the plugin should be smooth if you decide to do so.

> The reason Context.IO doesn't want the token is they are using two-legged> oauth as opposed to three-legged oauth which does seem to require the token.> The oauth_token has the same value as the oauth_consumer_key so it seems> redundant anyway. I am new to oauth myself so I don't know all of the> nuances of what is needed. I read the tutorial on oauth that is referred to> at the oauth.net site.

I'd be intrigued to know if this works with the scribe plugin, since
I've not knowingly made any allowances for 2-legged oauth. I'll knock
up a quick sample and see if I have any luck connecting to Context.IO
with the plugin.

The nuances of oauth appear to be central to oauth itself, I was
surprised that nobody had written an oauth2 plugin when I started
writing mine, and now I see why. Every single implementation is
completely different, and nobody respects the same formats for data,
it's actually a complete pain. Luckily, scribe abstracts me away from
most of that, but I notice that it has a custom API class defined for
most of the common providers.
Cheers,
Antony

On 29 December 2011 18:12, sethfuller <[hidden email]> wrote:

> I see your point about the convention over configuration. I'll tell the lead
> developer about signpost being abandoned and maybe we'll go with scribe. We
> have two providers now and may add more so we might go with scribe directly.
>
> The reason Context.IO doesn't want the token is they are using two-legged
> oauth as opposed to three-legged oauth which does seem to require the token.
> The oauth_token has the same value as the oauth_consumer_key so it seems
> redundant anyway. I am new to oauth myself so I don't know all of the
> nuances of what is needed. I read the tutorial on oauth that is referred to
> at the oauth.net site.
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Acessing-request-contents-in-oauth-plugin-tp4228813p4243570.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sethfuller]

I know that scribe works with Context.IO because Tom Taschauer has written a Java library for communicating with Context.IO (there 1.1 api they are now on 2.0). I forked it to do a minor fix on github at https://github.com/sethfuller/ContextIO.java. I may do a 2.0 version of this library. If you look in the doCall method of the ContextIO class you will see that he configures the service like this:

        OAuthService service = new ServiceBuilder().provider(ContextIOApi.class).apiKey(key).apiSecret(secret).build();

So his configuration is very simple. The ContextIOApi class is basically a no-op and throws UnsupportedOperationException exceptions for the getAccessTokenEndpoint, getAuthorizationUrl, and getRequestTokenEndpoint methods. This Java wrapper is just meant for communicating with the service after the user has an consumer key and secret.