Support for Application-only ('bearer') authentication for higher quota limits

[rtyley]

The Twitter API offers applications the ability to issue authenticated requests on behalf of the application itself (as opposed to on behalf of a specific user) - these requests are authenticated using bearer tokens and often have much higher API quota limits (eg on the search tweets endpoint you get 450, rather than 180, requests per 15 minute window):

twitter4s is an excellent library, although unfortunately it currently only supports user-auth so far as I can see - would it be possible to add app-auth for increased API quota?

See also: the PR adding application-only authentication to Twitter4J.

[rtyley]

Here's a gist showing end-users how they can hack support for Application-only ('bearer') authentication on top of twitter4s: https://gist.github.com/rtyley/dc341992a6104f4b499834fd2d10dfad

You can then create a new new AppOnlyAuthentication.TwitterRestClient(twitterConsumerToken) quite easily.

...I can probably find time to hack this a bit further into a proper PR if there's interest?

[DanielaSfregola]

Thank @rtyley, PRs are always appreciated!

Also, in twitter4s 6.0 we will have a client dedicated for app authentication -- it is probably what you are looking for: https://github.com/DanielaSfregola/twitter4s/blob/master/src/main/scala/com/danielasfregola/twitter4s/TwitterAuthenticationClient.scala

I'll try to cut the release version 6.0 -- people have been asking for its release for a while now!

Cheers,

[rtyley]

ooh, interesting - I was looking at the code around the new TwitterAuthenticationClient but I can't see where it hits the oauth2/token endpoint? I guess that's the part that isn't implemented yet?

[DanielaSfregola]

Correct! If you see https://github.com/DanielaSfregola/twitter4s/blob/master/src/main/scala/com/danielasfregola/twitter4s/http/clients/authentication/oauth/TwitterOAuthClient.scala you will see the endpoints for oauth authentication have been implemented: oauth2 ones are still missing.

Maybe all we need to do is to expand the soon-to-be-released TwitterAuthenticationClient to deal with oauth2 as well as oauth.

[rtyley]

Here's a gist showing end-users how they can hack support for Application-only ('bearer') authentication on top of twitter4s: https://gist.github.com/rtyley/dc341992a6104f4b499834fd2d10dfad

Note that the constructor-overriding-hack in this gist no longer works with twitter4s v6, due to PR #211 which makes those constructors private.

@DanielaSfregola, you did mention that TwitterAuthenticationClient in v6 would be an avenue for supporting App-only Authentication - but I get the impression that it's not yet integrated with the rest of the library yet? There's no way to to pass a TwitterAuthenticationClient to a TwitterRestClient for instance?

[DanielaSfregola]

At present there is no way to pass a TwitterAuthenticationClient to a TwitterRestClient -- and I am going to assume that implementing the missing functionalities for TwitterAuthenticationClient is going to take a while.

Happy to do a patch and make those constructors public again. Would this work?

Cheers, Daniela

[DanielaSfregola]

Thanks @rtyley for the PR - which I have released in twitter4s 6.0.1

Hopefully, we will add support for the application-only support soon, but this should at least allow you to keep you going until then!

Cheers, D.

[Shastick]

As an FYI: the workardoung still works like a charm. Just create the file from the gist (under the correct package) and this will get you going:

val restClient = new AppOnlyAuthentication.TwitterRestClient(ConsumerToken(key = consumerTokenKey, secret = consumerTokenSecret))

(Thanks for this library @DanielaSfregola ! :))

[Shastick]

@DanielaSfregola would you be Ok if we did the same hack with the streaming client?

(From a cursory glance changing the visibility of a constructor, as @rtyley did in https://github.com/DanielaSfregola/twitter4s/pull/239, should work the same)

[DanielaSfregola]

Hi @Shastick, no objections from me!

We could even add @rtyley's workaround into the library. Ideally, this shouldn't really be a "hack", the library should just support it....but unfortunately, I haven't had much time to work on this yet! :)

[Shastick]

That makes sense. Might find the time to do a proposal in a PR :)