Calling Twitter REST api from JavaScript with OAUTH

I’ve started on a project where I need to call Twitter’s REST apis from a Node.js JavaScript app. I’ve built a Java app before that integrated with Twitter, but used a library to help with the OAUTH authentication. Looking around for a JavaScript library, it looks like node-oauth does what I need to do, so gave it a go.

Twitter’s API docs are pretty good, but I ran into an issue with node-oauth with an error coming back from:

POST /statuses/update.json

which returned this message:

{ statusCode: 401,
 data: '{"errors":[{"code":32,"message":"Could not authenticate you."}]}' }

which is odd because using the node-oauth library to authenticate and then call any of the GET apis with node-oauth was working fine. If you Google this error there’s numerous posts about this error for all number of reasons, so I’m not sure it’s a particularly specific message.

Here’s a working example for a GET:

First, use node-oauth to authenticate with your Twitter key, secret, and app access token and secret (which you can set up here):

var oauth = new OAuth.OAuth(
    'https://api.twitter.com/oauth/request_token',
    'https://api.twitter.com/oauth/access_token',
    config.twitterConsumerKey,
    config.twitterSecretKey,
    '1.0A',
    null,
    'HMAC-SHA1'
);

Next, using the returned value from this call, make the GET request (it builds the request including the OAUTH headers for you):

//GET /search/tweets.json
oauth.get(
    'https://api.twitter.com/1.1/search/tweets.json?q=%40twitterapi',
    config.accessToken,
    config.accessTokenSecret,
    function (e, data, res){
        if (e) console.error(e);
        console.log(data);
    });

Attempting a POST to update the status for this account using the similar api:

var status = "{'status':'test 3 from nodejs'}";

oauth.post('https://api.twitter.com/1.1/statuses/update.json',
    config.accessToken,
    config.accessTokenSecret,
    status,
    function(error, data) {
        console.log('\nPOST status:\n');
        console.log(error || data);
});

And this is the call that returned the error about “could not authenticate”.

Looking through a few other tickets for the node-oauth project, this one gave a clue – this particular issue was about special chars in the body content to the POST, but it gave an example of the body formed like this:

var status = ({'status':'test from nodejs'});

I would have thought passing a String would have worked, but I guess the api is expecting an object? Anyway, this is working, and looks good so far.

Retro Battlestation (update 2): dialing up a local BBS with the 2002 Power Mac G4 Quicksilver

Since my first post after receiving my 2002 Power Mac G4 Quicksilver, I’ve learned a number of things about this machine.

Following the Retro Battlestations subreddit, there was a group activity a while back to dial into the group’s BBS using, yes, a real dial up modem, from your retro machine of choice. So I thought I’d give it a go.

The internal modem is on a board

Internal modem missing

about the size of a pack of cards, and it’s normally screwed to standoffs on motherboard in the top left of the motherboard in this photo. It was obviously removed in this machine, so that explains why an internal modem was not showing up as installed.

Not to be deterred, I noticed you can pick up an Apple USB modem for just $10 online so I ordered one. Wanting to give it a go truely old-style, I wanted to dial in from OS 9 – this is when I found out that this USB Modem is a ‘soft’ modem, in that it works mostly in software, and no, it’s not supported on OS 9.

In OS X 10.4 however, it gets recognized correctly as an External Modem in the System Preferences panel:

 

 

 

 

 

 

For a dial up terminal emulator for the Mac, I found most references pointing to ZTerm , so got it downloaded and installed, and it sees the USB modem. Got the BBS number configured, and off we go!

 

 

Success! Dialed in to the Level 29 BBS! I was expecting to see ANSI colors in the text display, so not sure if I need to change a setting in ZTerm, but so far pretty excited this works!

 

Using Netflix Eureka with Spring Cloud / Spring Boot microservices

I’ve been taking a look at this article on using Spring Cloud‘s integration/support for Netflix Eureka. I’ve started to put together a simple example using Eureka as a service registry for a couple of Spring Boot services, and what this would look like if deployed in Docker containers.

So far I’ve created the initial service that uses Spring Cloud’s @EnableEurekaServer annotation to start up the Eureka service.

Jumping ahead of the instructions, by default if you run this app it will attempt to reach out and find a local running Eureka server and register with it, but since this app is the Eureka server, you need to add config to tell the app not to do this by default. Otherwise you’ll see errors like:

com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.1.jar:1.19.1]
at com.sun.jersey.api.client.filter.GZIPContentEncodingFilter.handle(GZIPContentEncodingFilter.java:123) ~[jersey-client-1.19.1.jar:1.19.1]
at com.netflix.discovery.EurekaIdentityHeaderFilter.handle(EurekaIdentityHeaderFilter.java:27) ~[eureka-client-1.6.2.jar:1.6.2]

Adding the recommended config per the article:

server:

  port: ${PORT:8761}

eureka:

  client:

    registerWithEureka: false

    fetchRegistry: false

    server: waitTimeInMsWhenSyncEmpty: 0

Now when I start up I see this:

2017-04-11 22:23:17.040  INFO 37607 - o.s.c.n.eureka.InstanceInfoFactory       : Setting initial instance status as: STARTING
2017-04-11 22:23:17.100  INFO 37607 - com.netflix.discovery.DiscoveryClient    : Initializing Eureka in region us-east-1
2017-04-11 22:23:17.101  INFO 37607 - com.netflix.discovery.DiscoveryClient    : Client configured to neither register nor query for data.
2017-04-11 22:23:17.110  INFO 37607 -com.netflix.discovery.DiscoveryClient    : Discovery Client initialized at timestamp 1491974597110 with initial instances count: 0
2017-04-11 22:23:17.192  INFO 37607 - c.n.eureka.DefaultEurekaServerContext    : Initializing ...
2017-04-11 22:23:17.195  INFO 37607 - c.n.eureka.cluster.PeerEurekaNodes       : Adding new peer nodes [http://localhost:8761/eureka/]
2017-04-11 22:23:17.359  INFO 37607 - c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2017-04-11 22:23:17.359  INFO 37607 - c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2017-04-11 22:23:17.359  INFO 37607 - c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2017-04-11 22:23:17.359  INFO 37607 - c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2017-04-11 22:23:22.479  INFO 37607 - c.n.eureka.cluster.PeerEurekaNodes       : Replica node URL:  http://localhost:8761/eureka/
2017-04-11 22:23:22.486  INFO 37607 - c.n.e.registry.AbstractInstanceRegistry  : Finished initializing remote region registries. All known remote regions: []
2017-04-11 22:23:22.486  INFO 37607 - c.n.eureka.DefaultEurekaServerContext    : Initialized

Hitting http://localhost:8761 I get the fancy Eureka dashboard:

Looks good so far! More to come later.

Github repo for the code so far is here.

git error: “refusing to merge unrelated histories”

When working with local git repos, whenever I add a remote repo on github and then try to pull down the master from remote to local, I get errors about local repo not being on the same branch as the remote, or more recently this error:

fatal: refusing to merge unrelated histories

I think in the past I’ve done a ‘reset –hard’ like described here, but this didn’t work for me this time, I got the same error about ‘unrelated histories’

Turns out this might be related to a change in git behavior, as described here.

Doing:

git pull github master --allow-unrelated-histories

and then followed with:

git push github master

fixed my issue.