Custom version of extensions from the Chrome Web Store

Question

I develop and support the Chrome extension for my company, where each client will be assigned a unique identifier in the code. We used the identifier to determine the status of the license and enter our services (paid renewal with a monthly subscription fee).

Until now, we hosted the extension files themselves and had unique update URLs for each client extension. It was good and simple; go to our website, click "Install" and you're done. However, with the latest release of Chrome, this installation procedure was foiled by Google, as users now need to install extensions by dragging and dropping CRX files onto chrome: // chrome / extensions / tab. Unless, of course, the extension is available through the Chrome Web Store, which leads me to the problem:

• We do not want the installation of CRX with drag and drop - requires a web store.
• We do not want several versions of the extension (one for each customer) in the web store, as this is a hell of a hell for every time we update the extension.
• We do not want to use Web Store licensing because:
  • It requires OpenID login.
  • We sell the extension to schools with many students, where the school pays the bill, not the student.
  • We do not want to block our payment method in one browser, i.e. We want to be able to support licensing and payment through our or servers.
• We do not want users to enter a license key, because it is too risky when several thousand students have to enter a key - this also requires some kind of storage (cookie / localStorage), which will eventually be cleared, requiring a license key to enter again .

I am not 100% sure that my statements are absolutely correct, so do not hesitate to educate me if I missed something.

If so, the question arises, can we somehow adapt the extension for each client through the web store (using a unique identifier) ​​without the need to publish one extension per identifier?

As a side question, any answers that may solve the problem by another method will also be accepted.

Answer 1

For the answer below, I assume that your application is a packaged application, not a hosted application.

I have a solution that is quite similar to your current implementation, but adds one extra step for users. For the student user, the process will work as follows:

• Download the app from the online store. The application does not work yet, and when it starts, it simply displays the message "Please click on the activation link provided by your school / institution."
• Click the link hosted on your server (i.e. the server on which the update URL was hosted), which looks like https://myserver.com/activateapp.php?custid=123456789 . You have one such link for each institution that you support, and this is the task of the institution to provide a link to its students. This link activates the application.

In terms of implementation, here's how it works:

• On the server page, place the page https://myserver.com/activateapp.php . On the server side, verify that the custid parameter custid valid. If not, send 404 error.
• Your application has script content that is entered at https://myserver.com/activateapp.php , which scans the URL and selects the client ID. When the application finds the identifier, it stores it in localStorage. Since invalid client ids give a 404 error, you know that when running the contents of the script, the page is not a 404 error; therefore, it reads a valid customer identifier.
• Anytime an application wants to request your services, it checks to see if it has a client identifier in localStorage. If so, it uses this identifier; If this is not the case, a message appears stating that the application has not yet been activated. Packaged applications will never erase their localStorage unless your application is programmed to erase its own storage, or the user does this from the console. Erasing a vault will never happen "accidentally." Even the most powerful data / cache clearing in the browser clears only localStorage from web pages, and not from applications and extensions.

For added security - if you do not want people to randomly guess the customer IDs, you can add an additional signature parameter, for example, https://myserver.com/activateapp.php?custid=123456789&sig=2464509243 . This additional parameter is a server-verified conversion of the client identifier (ideally, a cryptographic signature or a purely random value associated with the identifier in the database), which cannot be guessed. When a request to activateapp.php hits the server, it checks for a valid client ID and a valid corresponding signature. Of course, this will not prevent people who have legitimate access to a valid link from sharing with unauthorized users, but I expect that this was a vulnerability existing in your old system.