Following up to this previous post - Major update to Twitter node coming - we have now published the new version of the Twitter node.
Upgrading to this version will be a disruptive upgrade - you will need to update your flows to continue accessing the Twitter service.
If you don't update, you'll no longer be able to use Twitter after June 12th 2018.
There are 2 parts to the update.
- Upgrade your Twitter node module to at least version 1.0.0
- Reconfiguring your Twitter nodes with new credentials to access the Twitter API
How to upgrade your Twitter node module
The exact steps to upgrade your twitter node module will depend on how you have Node-RED installed. This is because the Twitter node is installed as a dependency of the core Node-RED module, so may not be in your user directory - that means the Node-RED palette manager is not able to update it for you.
Brand new install of Node-RED 0.18.7
If you are doing a brand new install of Node-RED 0.18.7 (or later) then you will get the new version of the Twitter node. If you have already installed Node-RED 0.18.7 when you read this, then you'll still need to update the Twitter node separately.
If you have used our update script then you should find the Twitter node in
/home/pi/.node-red/node_modules. In a terminal, run the command:
cd /home/pi/.node-red npm install firstname.lastname@example.org
If you have not used our update script and are still using the preinstalled version, you will need to first run our update script to get onto the latest Node-RED. You should then find it has included the new version of the Twitter node already.
Running Node-RED < 0.18.7
We, of course, recommend that you upgrade to the latest Node-RED. In doing so, it should pull in the latest version of the Twitter node as part of the upgrade. If it doesn't, or you are not able to upgrade Node-RED for other reasons, read on...
Existing install of Node-RED 0.18.7
If you have installed Node-RED as a global module, using
npm install -g node-red, then you will need to find where that has put the module. In a terminal, run the command:
npm ls -g node-red-node-twitter
That will report where the twitter module is, if it can be found. For example:
$ npm ls -g node-red-node-twitter /Users/nol/.nvm/versions/node/v6.12.0/lib └── email@example.com
You can then upgrade the twitter node:
cd /Users/nol/.nvm/versions/node/v6.12.0/lib npm install firstname.lastname@example.org
npm ls command doesn't find the twitter node... and you aren't able to find it yourself, come ask for some assitance in slack and we can get these instructions updated to cater for whatever scenario you've hit.
If you are running the Node-RED boilerplate with the IBM Cloud, follow this instructions to upgrade to the latest Node-RED. That will pull in the new version of the Twitter node.
Configuring the new Twitter node
Once you've upgraded the node and restarted Node-RED, you'll need to reconfigure any Twitter nodes you have.
- Edit the Twitter credentials node
- Follow the link to https://apps.twitter.com and register your own application
- If you wish to work with Direct Messages, modify the app's permissions to include Direct Message access
- Generate a new Access Token on the Twitter Application page
- Copy the Consumer Key and Secret, and the Access Token and Secret into the node's edit dialog
Why do I have to do all this work?!
The old version of the Twitter node made use of a Twitter application we had registered for you. That meant it used our Consumer Key and Secret to access the API. This was never ideal as those sorts of credentials should not be shared around so freely.
Part of the authentication flow involves Twitter redirecting your web-browser back to Node-RED. To do that it used a field called the 'callback url'. When you register an application with Twitter, you could leave the callback url field blank, and then set it per-authentication request. That was very flexible as it let us use that one app regardless of whether you were running on localhost, on the IBM Cloud or anywhere in between.
From June 12th, Twitter require the callback url to be hardcoded in the application's registered details. That would break our node as we couldn't hardcode a url that worked for everyone in all circumstances.
Unfortunately we've had very little notification of this change and there is nothing we can do in the project to absorb the change for you. That's the risk of build applications against other people's APIs.