I created a small chrome extension for a specific scope of users. How can I make sure that a user is logged in only on one machine to avoid sharing the Extension without users paying for it?
Is there any way to do so?
With other apps I check the UUID and compare it against my list of users.
I struggle to understand the identify API tbh.
This is my way currently but it only tracks if the user is in my list. It is inside my popup.JS file so it gets triggered when the users click on the extension icon.
Edit:
(function () {
chrome.identity.getProfileUserInfo({ 'accountStatus': 'ANY' }, async function (info) {
email = info.email;
console.log(info.id);
let response = await fetch('https://pastebin.com/');
let data = await response.text();
console.log(data.indexOf(info.id));
if (info.id === '') {
chrome.browserAction.setPopup({ popup: 'index.html' });
alert(info.id);
} else if (data.indexOf(info.id) !== -1) {
console.log('License is valid');
} else {
chrome.browserAction.setPopup({ popup: 'index.html' });
alert(info.id);
// block chrome extension usage;
}
});
})();
Please note that my answer is based on my opinion. Feel free to use another answer if I happened to be wrong.
I assume that you have a server in which you use as the main database of your Chrome extension.
So, looking at your use-case, if I were you, I would try to implement a stateful data-store like Redis in order to store / cache the 'states' of the logged in users. When a user logs in, I will store their email in an easily-fetched data structure (preferably with O(1) complexity). If that user tries to log in using another machine, it'll be easily detected in the data store and you cannot use the extension in that machine — that is until that user logs out in the previous machine. You can even invalidate a session in your backend if you wish for it.
Why I chose Redis? It's because it's a data store strictly designed for high-performance applications. Mostly, it's used to cache sessions and states, but you can use it as a conventional database without much effort as well.
An implementation example:
Redis has a data structure that easily fits the above criteria. It's called a set. Set is a data structure that only allows unique elements.
If a user logs in.
akasha@Akashas-MacBook-Pro redis> % SADD auth <user_email>
akasha@Akashas-MacBook-Pro redis> % SREM auth <user_email>
akasha@Akashas-MacBook-Pro redis> % SISMEMBER auth <user_email>
The commands are pretty self-explanatory, SADD is to add a member to a set, SREM to remove, and SISMEMBER will return a boolean value whether value exists in the set or not. Perfect for session management!
You can also use several combinations of data structures to suit your use-case more throughly as well!
Such as using hashes for example:
Basically, it's like an object data structure in JavaScript. Let's say this is the command that will get executed in the Redis after the user logs in.
akasha@Akashas-MacBook-Pro redis> % HSET authentication:{user_email} email <user_email>
akasha@Akashas-MacBook-Pro redis> % DEL authentication:{user_email}
akasha@Akashas-MacBook-Pro redis> % HEXISTS authentication:{user_email}
References: