it-swarm.dev

Sicheres kostenpflichtiges WordPress-Plugin

Ich möchte ein WordPress-Plugin erstellen, aber auch sicherstellen, dass das Plugin nur verwendet werden kann, nachdem es mit einem Serienschlüssel aktiviert wurde, der für jede Domain eindeutig sein sollte.

Was ist der beste Weg, dies zu tun, vorausgesetzt:

  1. Ich muss den Benutzern den eigentlichen Quellcode geben und kann keinen VideoPress-Sicherheitstyp haben - das ist nur ein JavaScript-Wrapper für den eigentlichen Inhalt, der vom Server des Plugins stammt.
  2. Ich möchte sicherstellen, dass ein Anfänger, der ein durchschnittlicher PHP - Entwickler ist, die Sicherheit nicht leicht umgehen kann.
5
Adhip Gupta

Option 1 - Verarbeiten Sie einige Daten auf Ihrem System

Ich würde nicht die gesamte Verarbeitung des Plug-Ins auf Ihren eigenen Server stellen, sondern ein oder zwei wichtige Funktionen auswählen und auf Ihrem System bereitstellen. Benötigen Sie dann einen API-Schlüssel für jede Site, die das Plug-in verwendet, damit sie mit Ihrem Server kommunizieren können.

Option 2 - Verschlüsseln Sie gespeicherte Daten und benötigen Sie einen gehosteten Entschlüsselungsschlüssel

Eine andere Alternative ist ein grundlegendes Verschlüsselungs-Setup - dies ist eigentlich ein System, mit dem ich schon eine Weile gearbeitet habe. Ich habe mich nur noch nicht darum gekümmert, es irgendwo zu implementieren. Der Code selbst (um der GPL treu zu bleiben) besteht aus Klartext, genau wie Sie es erwarten würden. Alle gespeicherten Daten (Standardwerte, Plug-In-Einstellungen usw.) werden jedoch verschlüsselt, bevor sie in der Datenbank gespeichert werden. Der Trick dabei ist, dass das Plug-In auf dem Remote-System nicht über den Entschlüsselungsschlüssel verfügt. Um die Daten zu entschlüsseln, muss es seinen API-Schlüssel an Ihr System senden, das dann mit dem Entschlüsselungsschlüssel antwortet. Dies kann dann für einen bestimmten Zeitraum in einer vorübergehenden (temporären) Option gespeichert werden, bevor es gelöscht wird. Auf diese Weise wird bei starkem Datenverkehr nicht alle 2 Sekunden eine Site auf Ihren Server geschaltet.

Die Nachteile dieses Ansatzes könnten jedoch die Vorteile überwiegen (weshalb ich ihn noch nirgendwo bereitgestellt habe). Zunächst einmal kann ein versierter Programmierer den Entschlüsselungsschlüssel erfassen und benötigt dann Ihren Server nicht mehr. Oder sie könnten einfach alle Verschlüsselungs-/Entschlüsselungs-Hooks löschen und im Klartext ausführen. Dies ist der Vorteil von Open Source für den Benutzer und der Nachteil für den Entwickler, der ein freies, aber eingeschränktes System vertreiben möchte.

Der andere Nachteil ist die Abhängigkeit von Ihrem Server. Das Speichern eines Schlüssels in einem Transient entlastet Ihren Server zum Teil ... Wenn Ihre Site jedoch ein oder zwei Stunden lang ausfällt, fällt jede Site aus, die Ihr Plug-in verwendet ein oder zwei Stunden, es sei denn, Sie planen eine angemessene Deaktivierung. Dies würde auch bedeuten, dass Sie den Server auf unbestimmte Zeit betriebsbereit halten müssten, wenn die Benutzer Ihr System weiterhin verwenden.

Option 3 - Beschränken Sie die Funktionen der "kostenlosen" Version

Eine letzte Option, an der ich gerade arbeite, ist die Aufteilung des Featuresets und der Funktionalität Ihres Plug-ins. Der Kern des Systems (Benutzeroberfläche, Grundfunktionen usw.) ist ohne Registrierung frei verfügbar. Für erweiterte Funktionen müssen Benutzer ihre Kopie registrieren, einen Aktivierungsschlüssel erwerben und diesen dann in die Benutzeroberfläche eingeben, um den Vorgang abzuschließen. Das Plug-In überprüft dann Ihren Server und lädt zusätzliche Premium-Add-Ons auf das System herunter .

Der Nachteil hierbei ist, dass nach dem Herunterladen der gesamte Code auf der Website des Benutzers gespeichert wird und er unter der GPL das gesamte Paket weiterhin weitergeben kann. Der Vorteil ist, dass es nur einmal von Ihrem System abhängt und keinerlei langfristige Download-/Verarbeitungsunterstützung erfordert.


Unabhängig davon, wie Sie vorankommen möchten, müssen Sie entweder eine externe API auf Ihrem Server verwalten oder den Benutzern die vollständige Systemquelle bereitstellen. Wenn Sie einige Funktionen auf Ihrem System behalten, müssen Sie fast 100% Betriebszeit garantieren, damit es sich lohnt. Wenn Sie die vollständige Quelle bereitstellen, gibt es keine Möglichkeit (unter der GPL), zu verhindern, dass jemand anderes Ihr System neu verteilt.

4
EAMann

Sie können den Quellcode weder vor WordPress-Benutzern verstecken, noch dürfen Sie die Weitergabe Ihres Plugins aufgrund von Lizenzproblemen einschränken.

Sie erstellen ein WordPress-Derivat mit Ihrem Plugin und Ihre Benutzer haben das Recht, den Quellcode zu erhalten und ihn frei weiterzugeben (siehe die vier Freiheiten in freier Software ).

Vorausgesetzt, WordPress ist unter GPLv2 lizenziert und Sie haben Kunden außerhalb der USA, sollten Sie sich mit den Auswirkungen einer GPL-Verletzung befassen, die Sie möglicherweise in Ihrem ("geschützten") Produkt haben.

Sie versuchen, eine Anbietersperre für Ihre Benutzer zu implementieren.

3
hakre

Die einzige Möglichkeit, ein verteiltes Plugin mit einer sicheren Lizenz zu haben, die ein halbwegs anständiger Programmierer nicht hacken kann, besteht darin, die Hauptfunktionalität des Plugins auf Ihrem eigenen Server wie Akismet auszuführen. Der Benutzer muss eine Anfrage an Ihren Server senden, die seinen Lizenzschlüssel enthält. Wenn der Schlüssel auscheckt, führen Sie den Quellcode an Ihrem Ende aus und senden Sie die Ergebnisse zurück.

2
John P Bloch