Restricting api.twitter.com to SSL/TLS traffic

fanaticly · 2014-01-10T17:15:41.000Z

Will this also break calls to the TWRequest API in iOS apps? That is, do we need to update the NSURLs we use from http:// to https:// ?

EPEelche · 2014-01-13T11:47:16.000Z

Good morning. I’m developing a web to capture and send tweets and I received the news that as of January 14 using a SSL cerfiticate to use the Twitter API is required.
I have seen that you can get with Verisign and Digicert. My question is Can I use another certificate from another company? What requirements should meet?

lfcipriani · 2014-01-13T18:09:43.000Z

If these URLs are connecting to api.twitter.com, yes, you need to update it.

lfcipriani · 2014-01-13T18:12:50.000Z

Usually HTTP client libraries available for the language you are using already handle SSL requests. For api.twitter.com you must use only Verisign certificates, given that other certificates won’t be validated by your clients.

Please, read the documentation about Connecting to Twitter API with SSL: https://dev.twitter.com/docs/security/using-ssl

EPEelche · 2014-01-14T08:08:00.000Z

Okay, another question: the only valid certificate for api.twitter.com is Verisign Class 3 Secure Server CA - G3? Are there other valid alternatives?

PointBurst1 · 2014-01-14T08:31:06.000Z

Could you please specify if it is enough to upgrade the twitter4j library or you just fixed your local version? Thanks in advance

lfcipriani · 2014-01-14T11:14:38.000Z

Yes, and there’s no other valid alternatives.

HakimGhoula · 2014-01-14T13:05:43.000Z

I’m using Twython to read from user_timeline and last night my script was working fine now it doesn’t. I don’t have any http or https in my code so I guess that is handled by twython. Only thing is I was under the impression that it uses https per default. Why am I getting 401s now and how do I go about fixing it?

lfcipriani · 2014-01-14T16:27:21.000Z

The deploy of this change will start at 11am PST, so at the time of writing it didn’t start yet. Your problem can not be related to SSL restriction. But would be interesting to check Twython source code to check if everything will be fine after the restriction is applied.

HakimGhoula · 2014-01-14T18:17:33.000Z

Seems very strange that a script that works fine all of a sudden stops working while running and thus have had no changes to code or dependencies from working state to not working state.

Has anything been changed to oauth version 2?

EDIT: I have now made a new app and it seems to work, now I’m anxious to see if it will also get the same problems.

Al_Sweetman · 2014-01-14T17:15:27.000Z

I’ve an interesting one here - Hosebird has stopped functioning, today.

Even the “sample code” in the repository returns an IOException (the same as what I’m seeing) - “2014-01-14 17:05:20,506 [hosebird-client-io-thread-0] WARN com.twitter.hbc.httpclient.ClientBase.establishConnection.184 - Hosebird-Client-01 IOException caught when establishing connection to https://stream.twitter.com/1.1/statuses/filter.json?delimited=length&stall_warnings=true”

Debugging this, under the covers, I see a request to “Connect to stream.twitter.com:80 timed out”. How bizzare!

It seems quite coincidental that this is just happening, today, on the day of the switch over. What I can’t understand, however, is where the “http” request comes in at all when everything from within hosebird is set up to use https.

Al_Sweetman · 2014-01-14T17:21:53.000Z

Code below: This is what’s happening with my “proper” client as well as the test client I just created for a proof-of-concept. Incidentally developed against Hosebird 1.4.0


import com.google.common.collect.Lists;
import com.twitter.hbc.ClientBuilder;
import com.twitter.hbc.core.Client;
import com.twitter.hbc.core.Constants;
import com.twitter.hbc.core.Hosts;
import com.twitter.hbc.core.HttpHosts;
import com.twitter.hbc.core.endpoint.StatusesFilterEndpoint;
import com.twitter.hbc.core.event.Event;
import com.twitter.hbc.core.processor.StringDelimitedProcessor;
import com.twitter.hbc.httpclient.auth.Authentication;
import com.twitter.hbc.httpclient.auth.OAuth1;
import java.util.List;

import java.util.concurrent.BlockingQueue;

import java.util.concurrent.LinkedBlockingQueue;
/**


Created with IntelliJ IDEA.

*/

public class TwitterTest

{

public static void main(String[] args )

{

String consumerKey = “XXX”;

String consumerSecret = “XXX”;

String token = “XXX”;

String secret = “XXX”;
 /** Set up your blocking queues: Be sure to size these properly based on expected TPS of your stream */
 BlockingQueue<String> msgQueue = new LinkedBlockingQueue<String>( 100000 );
 BlockingQueue<Event> eventQueue = new LinkedBlockingQueue<Event>( 1000 );



/** Declare the host you want to connect to, the endpoint, and authentication (basic auth or oauth) */

Hosts hosebirdHosts = new HttpHosts( Constants.STREAM_HOST );

StatusesFilterEndpoint endpoint = new StatusesFilterEndpoint();

List terms = Lists.newArrayList( “twitter”, “api” );

endpoint.trackTerms( terms );
    Authentication hosebirdAuth = new OAuth1( consumerKey, consumerSecret, token, secret );
    ClientBuilder builder = new ClientBuilder()
            .name( "Hosebird-Client-01" )                              // optional: mainly for the logs
            .hosts( hosebirdHosts )
            .authentication( hosebirdAuth )
            .endpoint( endpoint )
            .processor( new StringDelimitedProcessor( msgQueue ) )
            .eventMessageQueue( eventQueue );                          // optional: use this if you want to process client events

    Client hosebirdClient = builder.build();

    hosebirdClient.connect();
    int count = 0;
    while ( !hosebirdClient.isDone() && count++ < 10 )
    {
        String msg = null;
        try
        {
            msg = msgQueue.take();
        }
        catch ( InterruptedException e )
        {
            e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
        }
        System.out.println( "message  " + msg );
    }
    hosebirdClient.stop();
}

}

Al_Sweetman · 2014-01-14T18:16:06.000Z

Investigations reveal that there is a bug in RestartableHttpClient which I’m going to try to write a patch for whereby it doesn’t respect the https scheme if it’s present when constructing HttpHost instances.

lfcipriani · 2014-01-14T18:19:57.000Z

Indeed, this is not a problem related to this change. Glad that you found the bug.

lfcipriani · 2014-01-14T19:39:47.000Z

The change was deployed at 17:25 UTC (Jan 14, 2014)

EPEelche · 2014-01-14T19:53:32.000Z

Thanks

pgarvie · 2014-01-14T20:01:15.000Z

Thanks Luis. Nice job!!

PaulG

followfever_com · 2014-01-14T22:30:59.000Z

I get the same troubles that one week ago (during several hours). I do not know what is wrong…

newsytweets · 2014-01-14T22:49:45.000Z

I am positive that I am using the https endpoint, but still getting 403 error code. Anyone else seeing the same problem? I am using Net::Twitter perl module. I checked the source code and it is indeed using https.

Cornel74 · 2014-01-14T23:12:20.000Z

I had a similar problem you could try the apiurl parameter to supply an alternative API url. It seems to be defaulting to http://api.twitter.com/1

I fixed my 403 errors by adding: apiurl => ‘https://api.twitter.com/1.1’