Plugin sécurisé WordPress payant
Je souhaite créer un plug-in WordPress, mais je souhaite également m'assurer que le plug-in ne peut être utilisé qu'après avoir été activé avec une clé de série qui devrait être unique pour chaque domaine.
Quelle est la meilleure façon de s'y prendre en supposant:
- Je dois donner le code source réel aux utilisateurs et je ne peux pas avoir un type de sécurité VideoPress - qui est juste un wrapper JavaScript pour le contenu réel qui provient du serveur du plugin.
- Je veux m'assurer qu'un développeur novice en moyenne PHP ne sera pas en mesure de contourner facilement la sécurité.
Option 1 - Traiter des données sur votre système
Je ne voudrais pas placer tous les traitements du plug-in sur votre propre serveur, mais choisir une ou deux fonctions vitales et les héberger sur votre système. Ensuite, demandez une clé API pour chaque site utilisant le plug-in afin qu'ils puissent communiquer avec votre serveur.
Option 2 - Crypter les données stockées et nécessiter une clé de décryptage hébergée
Une autre alternative est une configuration de cryptage de base - il s’agit en fait d’un système avec lequel je joue depuis un moment, je n’ai simplement pas pris la peine de le déployer où que ce soit. Le code lui-même (pour rester fidèle à la GPL) est tout le texte en clair comme vous vous en doutez. Cependant, toutes les données stockées (valeurs par défaut, paramètres de plug-in, etc.) sont cryptées avant d'être enregistrées dans la base de données. L'astuce ici est que le plug-in sur le système distant n'a pas la clé de déchiffrement. Pour déchiffrer les données, il doit publier sa clé API sur votre système, qui répond ensuite avec la clé de déchiffrement. Cela peut ensuite être stocké dans un transitoire (option temporaire) pendant un certain temps avant d'être vidé. Ainsi, aucun site ne frappe votre serveur toutes les 2 secondes lorsque le trafic est intense.
Les inconvénients de cette approche pourraient toutefois l'emporter sur les avantages (c'est pourquoi je ne l'ai pas encore déployée). Tout d’abord, un programmeur avisé peut capturer la clé de déchiffrement et n’a plus besoin de votre serveur. Ou ils pourraient simplement éliminer tous les points d'ancrage de cryptage/décryptage et s'exécuter en texte brut. C'est l'avantage de l'open source pour l'utilisateur et l'inconvénient du développeur qui souhaite distribuer un système libre mais restreint.
L'autre inconvénient est la dépendance sur votre serveur. Stocker une clé dans un transitoire soulève une partie de la charge de votre serveur ... mais si votre site tombe en panne pendant une heure ou deux, alors chaque site utilisant votre plug-in s’étend pendant une heure ou deux à moins que vous ne planifiiez une sorte de désactivation gracieuse. En outre, cela signifierait que vous devrez maintenir le serveur en marche indéfiniment si les utilisateurs continuent à utiliser votre système.
Option 3 - Limiter les fonctionnalités de la version "gratuite"
Une dernière option, et sur laquelle je travaille activement, consiste à diviser l'ensemble des fonctionnalités et des fonctionnalités de votre plug-in. Le noyau du système (interface utilisateur, fonctionnalités de base, etc.) est librement disponible sans inscription. Pour des fonctionnalités plus avancées, les utilisateurs doivent enregistrer leur copie, obtenir une clé d'activation, puis entrer cette clé dans l'interface utilisateur pour terminer le processus. Le plug-in vérifie ensuite auprès de votre serveur et télécharge des "add-ons" premium supplémentaires sur le système. .
L'inconvénient est que, une fois téléchargé, tout le code repose désormais sur le site de l'utilisateur et, selon la licence GPL, il est toujours possible de redistribuer l'intégralité du package. L'avantage est que cela ne dépend qu'une seule fois de votre système et ne nécessite aucun type de support de téléchargement/traitement à long terme.
Quelle que soit la façon dont vous décidez d’aller de l’avant, vous devrez soit maintenir une sorte d’API externe sur votre serveur, soit fournir à vos utilisateurs la source complète du système. Si vous conservez certaines fonctionnalités de votre système, vous devez presque garantir une disponibilité de 100% pour que cela en vaille la peine. Si vous souhaitez fournir le code source complet, il n’est pas possible (dans le cadre de la licence GPL) d’empêcher une autre personne de redistribuer votre système.
Vous ne pouvez pas cacher le code source aux utilisateurs de WordPress, et vous n'êtes pas autorisé à limiter la redistribution de votre plugin en raison d'implications en matière de licence.
Vous créez un dérivé de WordPress avec votre plugin et vos utilisateurs ont le droit d’en récupérer le source et de le redistribuer librement (voir les quatre libertés du logiciel libre ).
En supposant que WordPress soit sous licence GPLv2 et que vous avez des clients non américains, vous devez gérer les implications d'une violation de la GPL que vous pourriez avoir dans votre produit ("protégé").
Vous essayez d'implémenter un verrouillage du fournisseur pour vos utilisateurs.
Le seul moyen d'avoir un plug-in distribué doté d'une licence sécurisée que tout programmeur honnête ne peut pas pirater est d'exécuter la fonctionnalité principale du plug-in sur votre propre serveur, comme Akismet. L'utilisateur doit envoyer une requête à votre serveur contenant sa clé de licence. Si la clé est vérifiée, exécutez le code source de votre côté et renvoyez les résultats.