I am creating my first WordPress plugin. It is a Twitter plugin that uses Twitter API 1.1 and OAuth 2.0 to generate a bearer token and then use that to fetch Tweets from Twitter.
The plugin is almost ready to be launched.
Right now, the user of the plugin will need to go here: https://developer.twitter.com/en/apps/create
and create a new app, filling in all details, so that they can generate their Consumer API key & secret to use with my plugin.
As soon as they do that, my plugin will fetch a bearer token for them. My plugin only needs “Read” permission.
I have seen many plugins do it this way. But it definitely seems like a very tedious step to follow for the user in order to use the plugin.
My questions are:
- Is it the right method?
- Is there a better way to approach this?
- Should I somehow, store my Consumer API key & secret details on my
server? And any of my distributed plugins should automatically fetch
it from my server? - Further, are the Consumer API key & secret associated with my
Twitter app, meant to be distributed with my Twitter plugins?
Answers to these questions would clear a lot of mystery for me around this topic.
Thanks in advance.
1 Answer
I have seen many plugins do it this way. But it definitely seems like a very tedious step to follow for the user in order to use the plugin…
Is it the right method?
Yes.
Should I somehow, store my Consumer API key & secret details on my server? And any of my distributed plugins should automatically fetch it from my server? Further, are the Consumer API key & secret associated with my Twitter app, meant to be distributed with my Twitter plugins?
NO to all of these. And if I could use larger letters than all caps, I would.
There are a number of reasons for this.
First, as the developer of a plugin that will use the Twitter API, you personally are not the API user. That would be the user of your plugin. Allowing your plugin users to use your API credentials would be a violation of Twitter’s policies.
Additionally, this is just a bad practice. You have no control over the end user of the plugin and how they ultimately use the service. You’d be putting yourself in a situation where, if Twitter decided some end user of yours was in violation of the terms of use, they could yank the credentials.
You might think this is not possible, or that it’s low risk because you’re just reading, but what if someone decides to modify the plugin itself and is able to hack things in a way that puts your use of the API in violation of Twitter’s terms?
In other words, a single end user of your plugin could jeopardize the API use by both you and all of your other plugin users. There is the potential that you wake up one morning, open your email, and find you are flooded with support tickets asking why the service is shut down.
Read the developer policies carefully and understand that what you are providing is a product that uses the Twitter API. You’re not providing a connection to the API.
Beyond all of that, it also depends on how your plugin will be distributed. If you’re planning on wordpress.org repo distribution, storing the API key on your server for your plugin to retrieve could be viewed as be a violation of the repo’s policies on “phoning home.” It’s a gray area, so it depends on the opinion of who is doing the review at the time, but why not just do it right to begin with and avoid a potential hassle?