Application-only authentication for 1.1 search api


#1

sorry for asking this question again but I didn’t get a response last month on it.

I keep seeing references that the application-only authentication is coming soon to 1.1. When will this happen and can you tell us more about the implementation? With the March deprecation coming soon, we need time to figure out our options and write our code.


#2

We’ve not yet announced the shape and definition for how this form of auth will work – don’t have a date for you on it either.

But the limitations on this form of auth will still be such that leveraging access tokens belonging to Twitter users will be the correct way to scale usage of any of our APIs.

Application-only auth will be rate limited per API key, with no user context or IP address context adding to the mix – the rate limit pool for a method like the search API for application-only contexts will allow for a small number of queries per rate limit window, but not necessarily enough to provide a search interface to 100s of users without requiring you to leverage their access tokens.

Overall, for anything you’re waiting for in application-only auth, you can likely accomplish it today by using a dedicated application-oriented account and OAuth 1.0A instead.


#3

The problem we have is that our software is server based. It’s a parser that reads twitter queries from our database and populates our database with the tweets from those queries. We don’t use user authorization, just application authorization from our parser application. I’m not even sure how I could add user authorization to my parser.


#4

First, you’ll need to register an application now if you haven’t already.

Click your username in the upper right hand corner and select “My Applications” from the drop down.

Then, create a new application. After your application is specified, you have your consumer key and secret.

Next, have the web site create your access token – there’s a button there (I forget its exact wording).

At that point, you have a consumer key & secret and an access key & secret, which is what you need for your server process to authenticate.

If you are using Java, then the code will look something like:

tf = new TwitterFactory(); connection = tf.getInstance(); AccessToken at = new AccessToken("access-key-goes-here", "access-secret-goes-here"); connection.setOAuthConsumer("consumer-key-goes-here", "consumer-secret-goes-here"); connection.setOAuthAccessToken(at);

With the keys and secrets substituted into the calls, of course.


#5

Charles,

I have application authorization working fine. I’m just fighting with how to add user authorization to an app that is a dotnet exe.


#6

When you search tweets and they tweets for one particular twitter account?


#7

No, they can search anything that the search api gives us. So all works ok with api 1.0 with our parser running on several systems. However, because I don’t have user authorization implemented for my api 1.1 version, I have all systems sharing the same rate limit. So, it looks like all I need to do now is add user authorization on top of the application authorization I have correctly implemented. But, I’m still trying to figure out how to write that code. All samples I’ve seen have a UI and are asp.net based. Although my exe currently has a UI, I want to move it to a windows service with no UI. So, how to create user authorization without a UI.


#8

There are a few ways you can accomplish this – I’ll speak less specifically about a programming environment and more about how this scenario can be handled.

  • If you can register a custom URI scheme at the operating system level, you’ll want to go this route:

    • Get a request token from oauth/request_token, dynamically setting your oauth_callback value to point to your custom URI scheme
    • Create an authorization URL from the request token, either display the URL to the end user and ask them to paste it into a web browser or open the URL up in a web browser.
    • Once the user completes the login process, they’ll be redirected to the URL you specified as your oauth_callback with additional information you need to…
    • Issue the request to exchange the request token for an access token on oauth/access_token
    • persist the access token when making requests on behalf of the user from that point on
  • If you can’t register a custom URI scheme, you’ll want to go this route:

    • Get the request token from oauth/request_token but set your oauth_callback value to “oob” (it means out-of-band authentication)
    • Create an authorization URL from the request token, either display the URL to the end user and ask them to paste it into a web browser or open the URL up in a web browser.
    • Once the user completes the login process, they’ll be presented with a PIN code
    • In your console application, provide an input for that PIN code
    • Once the PIN code is received, use it as your oauth_verifier value when making the exchange of request token for access token on oauth/access_token
    • persist the access token when making requests on behalf of the user from that point on

At some point, you’re going to have to send the user to a web browser to complete the authorization flow.


#9

I think you should just try using your own twitter account for the user authorization, this is just a one off process.

If you haven’t done it already you can register your application in your twitter account :
https://dev.twitter.com/

Once your application is added in there you can authorize that application to your own user account - I did it earlier today but cant remember the exact wording.

Once you have done that you will then have a consumer key, consumer secret, oauth token and oauth secret.

The first 2 relate to your application and the last 2 relate to a particular twitter user - in this case is happens to be your user account rather than any other titter user.

Hopefully that will enable you to go and use the new search api.


#10

Hard-coding a single user account is an allright scenario for a single-user, non-distributed use case. But the rate limit for a user-application combination is finite and has no concept of “application instance” or IP address to further curry the rate limiting. By distributing a single-user token, all instances would share the same rate limit from that account, rather than each instance having its own user and its own limits.


#11

I’m still faced with a problem. I want my search parser to be a windows service and hence have no UI. So, there’s no way I can direct a user to pin authorize. That’s why I was hoping that application authorization only would come to the rescue.

BTW my parser works perfectly fine with the twitter api 1.0 with no authorization. It’s looking more and more like 1.1 is making this impossible.


#12

You don’t need to direct a user to authorize because you can do the authorization (using your own twitter account) as a one time thing, outside of the service. (as per my last posting). Your twitter account will be authorized to use your application so this information can be put into the windows service and then there is no need for anyone else to log into twitter from your windows service or anything.

I’m in a similar situation where I just have a website written in asp.net and want to show tweets from my client’s twitter feed on the web site, but I don’t want anyone to be logging on to twitter when visiting the website.


#13

I will be running many instances of this server (on different servers) so I can’t get away with just one user. So, is it just a matter of registering a unique twitter user for each instance? If I register a user for an appllication (using pin authorization), does that mean I won’t have to reauthorize that user for the application in the future?


#14

https://dev.twitter.com/docs/rate-limiting/1.1
I see search is limited to 180 queries every 15 minutes, so if that’s not enough for all your server instances then yes you could use a different user for each server instance.

Yes you only need to authorize an application for a twitter user once.

I see 2 options :

  1. Say you have 10 servers running this windows service (for example) you could have 1 application registered against 1 of your twitter users and then create 9 more twitter accounts and authenticate those against the same application. Have a config file on each server with different access tokens and access token secrets that the exe / service picks up on. (so each one knows which of the 10 users its supposed to use).

  2. Set up 10 twitter accounts and register a different application for each of them. Have a config file for each server containing consumer key, consumer secret, access token, access token secret. (Each server instance is told which application to use as well as which user).

#2 has the advantage that you can authorize users against applications totally in your twitter control panel, without having write .net code to achieve this.

I have a .net console app and i’ve added a reference ti Twitterizer2.dll that I downloaded, the code is :

        OAuthTokens tokens = new OAuthTokens();
        tokens.AccessToken = "xxx";
        tokens.AccessTokenSecret = "xxx";
        tokens.ConsumerKey = "xxx";
        tokens.ConsumerSecret = "xxx";
        TwitterResponse<TwitterStatusCollection> tweets = TwitterTimeline.UserTimeline(tokens);

That reads a collection of tweets for the user you have authenticated for (the twitter use that access token and access token secret relates to.
I’m not sure about doing search though.


#15

Thanks for everyone’s help. I finally made sense of it all.


#16

This kind of distributed dedicated user and application scenario could easily be seen as an attempt to circumvent rate limits. I would not recommend it. The spirit of the limits are that you would have one application record encompassing your application or service. Creating multiple users or applications just to get around rate limiting is not in the spirit of the model.


#17

I didn’t think we were attempting to increase the rate limits. We were just trying to find a way for each of the servers to run with its own rate limit. Because as I have it now, i only had application authorization so all servers were sharing one rate limit which only took about 3 servers to sink it. So, the goal now is to have one unique user per server where each server is running our twitter application.


#18

Hi Charles, can you convert this code in PHP please ?? Thanks !