Applications pending approval will return a different response body than what is presently supported.
Below is a copy of the actual response that comes back in this scenario:
```
{"status":401,"rateLimitTimeout":null,"body":{"request":"/1.1/statuses/update.json","error":"Read-only application cannot POST."}}
```
Whereas the current implementation assumes the presence of an `errors` array, reading off the first element (i.e. `result.body.errors[0]`), the above scenario throws an exception as `result.body.errors` is now `undefined` and cannot be indexed).
The proposed update seeks to account for this while retaining existing functionality and has been tested (error message in debug now properly says "Read-only application cannot POST."
Added support for version 3.
All the existing issues with v1 and v2c are also with v3 e.g.
https://github.com/node-red/node-red-nodes/issues/679
snmp walker will not return more than 1000 objects, all following objects cannot be accessed
Incorrect encryption (privacy) passphrase gives a timeout and not an error (protocol limitation?)
Incorrect community string gives a timeout and not an error (protocol limitation?)
Changes to the node are made with following details:
Node-red v1.2.2
Node.js v12.6.0
Windows_NT 10.0.19841 x64 LE
Pushbullet dev here. Around 36 hours ago we started receiving around 750 additional requests per second to connect to our stream server. I blocked around 50 - 100 IP addresses to mitigate the spam. This spam traffic has continued unchanged since then.
I don't know for sure what caused this, but one user came forward reporting issues with their Node-Red setup after I banned the IPs (status code is my banned IP status code which is pretty compelling evidence). I can't be sure what is causing the issue since no User-Agent is included in the requests, but it for sure is at least partly Node-Red API users. I'd like to work on mitigating this since mitigating the spam traffic costs money.
My first theory here is in this PR. I am not aware of any guarantees that you'll never get multiple 'error' events, so it makes sense to clear the timeout before setting a new one to reconnect. Even if it is just defensive, it may not have much cost? If you do get multiple error events without this change, it is possible to trigger many connect() requests which can error out and then trigger many more connect() requests with lots of timeouts, which is not good.
Another thing to consider is that this library's dependency for PB (https://github.com/alexwhitman/node-pushbullet-api) already has code to reconnect if a websocket connection is lost without having been properly closed. I think an even better solution is verifying this works and then deleting the reconnect logic from here.
I'm not an expert on Node-Red though so I am only trying to offer suggestions to ensure everyone is a good citizen when using our API :) Thanks!
