Skip to main content

Setting up Chrome extensions with a free trial period

I've been working on chrome extensions recently and while most of the area is well documented and pretty easy to figure out, I found setting up a free trial period to be really difficult. I ended up engaging an expert to help and have documented the steps required to help other people.

1. Publish your app on the Chrome web store if you haven't already done so and set up free trial billing.

2. Setup an app in the Google dev console and obtain the client_id. Sub steps below:

a. Create the project
b. Enable "Chrome Web Store API" for this project
c. Create application using the ID from the extension in the chrome store and when they ask you to setup credentials, choose: "OAuth client ID"

3. Add this to manifest.json:

4. Add a key to the manifest. This allows you to test the extension locally in developer mode. You can get the key in the Chrome developer dashboard if you click on the "More info" for your extension.

The key will be something like this.

Make sure you remove spaces before adding it to your manifest. (When you copy it from the dev dashboard, it has unnecessary whitespace on the right hand side).

5. Check that you have same id in the store and in the chrome://extensions tab for you testing copy.

6. Add code to check the licence (note that I'm hardcoding 14 days as the free trial period - change as desired):

This needs to go in as a background script in your manifest.json, e.g.
"background": {
        "scripts": ["checkLicenceKey.js"],
        "persistent": false
Then in your content script, you'll do something like this:
(You can see I've set up config for allowed email addresses for myself and for people who've paid offline.)

7. Profit!

Things I did wrong along the way:
1. Leaving whitespace in the key
2. Trying to test with the same account I used to set up the extension on the web store. This doesn't work. You'll need to test with a different account.


Popular posts from this blog

Getting current time in a specified timezone using Deluge script

Recently I was working on a custom function for Zoho CRM which required me to get the current time in a specified timezone. I assumed that zoho.currenttime would give me the time based on the timezone chosen in the organisation settings but discovered that it always gives it to you in PST. The Zoho Partner team gave me this snippet to solve the problem: current_time_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", "Australia/Sydney").toTime("yyyy-MM-dd'T'HH:mm:ss"); If you need the current date, do: current_date_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", timezone).toDate(); To figure out what you can put in for the timezone part, refer to

searchRecords with multiple criteria in Zoho CRM API

NB: this blog post is no longer relevant as API v2 lets you use searchRecords with multiple criteria :) I discovered something really cool tucked away in the Zoho CRM forums today. For the history, check out this thread . In summary, the searchRecords API task in Zoho CRM is impossible to use if you have multiple criteria and in general it's pretty annoying to get the single criterion right. In the forum thread, Zoho Support advised that you can actually use getRecords with a view name. This feature is not documented on the getRecords page at all but I can confirm it works:D This is really, really cool. It's going to make my life as a Zoho dev much easier! Instead of having to do something really inefficient and ugly like: leadRecords = zoho.crm.searchRecords("Leads","(Created Time|<|" + yesterday_date +")",fromIndex,toIndex); for each ele in leadRecords { lead_source = ele.get("Lead Source"); createTime=(ele.g

Debugging Deluge script in Zoho Creator/Zoho CRM

Deluge is a powerful language that simplifies a ton of things, e.g. database lookups. But I have to say, it's very painful to debug. Interpreting longish scripts takes ages, error messages are obtuse if they exist at all and even the hints in the IDE don't always help (ever tried using containsIgnoreCase based on the auto-complete suggestion?). Here are my tips for debugging code when it's not working. 1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors. 2. If