Wie kann ich mein Plugin sichern, damit nur zahlende Benutzer es verwenden können?

Ich entwickle einige (WordPress) Plugins und plane eine Lizenzgebühr für jeden, der es verwenden möchte.

Daher brauche ich einen Weg, um sicherzustellen, dass dieses Plugin nicht auf einen Server hochgeladen wird, wo jeder es herunterladen und kostenlos verwenden kann.

Also dachte ich an die Verwendung eines API-Schlüssels. Gültiger API-Schlüssel = Benutzer kann das Plugin verwenden. Ungültig = Plugin funktioniert nicht.

Ich habe mir diesen Beitrag PHP API Key Generator angesehen, aber ich werde nicht viel klüger.

Ich weiß auch, dass, da es sich um PHP handelt, jeder in den Code gehen und die API-Prüfung deaktivieren kann (ich vermute nur).

Wie kann ich mein Plugin am besten sichern? API-Schlüssel? Andere Möglichkeiten? Hat jemand einen Link zu guten Tutorials zu diesem Thema?

Wenn Ihr Plugin hängt davon ab Interaktion mit Ihrem eigenen Server Ein API-Schlüssel ist eine hervorragende Möglichkeit, nicht zahlende Benutzer daran zu hindern, ihn zu verwenden.
Wenn es jedoch nicht mit Ihrem Server interagieren muss, kann jeder mit ein wenig PHP-Kenntnissen Ihr Plugin ändern, um die API-Schlüsselprüfung zu entfernen.

Ein großes Problem hierbei ist die Lizenzierung für Ihr Plugin. WordPress ist GPL, und die GPL hat eine Klausel, die verlangt, dass „abgeleitete Werke“ auch unter der GPL lizenziert werden. (Das ist eine Untertreibung: Tatsächlich basiert die gesamte GPL auf dieser Klausel und würde ohne sie nicht wirklich funktionieren.)
Es gibt viele Diskussionen darüber, ob ein Plugin als „abgeleitetes Werk“ betrachtet werden kann. Meiner Meinung nach ist dies nicht der Fall, und ich halte es für unethisch zu versuchen, es als solches zu sehen. Automattic, die WordPress-Kernentwickler und die Free Software Foundation (die Organisation, die die GPL geschrieben hat) behaupten jedoch, dass WordPress-Plugins gesetzlich verpflichtet sind, die GPL zu verwenden und keine andere Lizenz verwenden dürfen.
Bisher gab es keine Gerichtsverfahren und daher keinen Präzedenzfall, aber es gibt beträchtliche Feindseligkeit in Bezug auf einige große WordPress-Plugins, die die GPL nicht verwenden, und Automattic hat im Grunde mit rechtlichen Schritten gedroht, während der Plugin-Entwickler sagte: „Bitte verklag mich doch”. Nicht gerade eine schöne Situation, und ich würde sagen, dass unabhängig von der Moral der Situation die Tatsache ist, dass die negative Publizität normalerweise die Vorteile des Closed-Sourcing eines Plugins überwiegt.

Zusammenfassend: Ihr Plugin muss grundsätzlich GPL sein, was bedeutet, dass Sie unverschlüsselten Quellcode bereitstellen müssen, damit jeder Ihr Plugin ändern kann, um alle von Ihnen hinzugefügten Einschränkungen zu entfernen. Aber es sollte für Sie einfach sein, die meisten Ihrer potenziellen Kunden davon zu überzeugen, das Plugin bei Ihnen zu kaufen, anstatt eine Fork-Version zu verwenden – Sie können Vorteile wie Support, Upgrades usw. usw. anbieten, die für a wahrscheinlich nicht verfügbar sind “gecrackte” Version.

Es gibt mehrere Unternehmen, die Plugins erfolgreich unter der GPL und ohne Schutz (API-Schlüssel usw.) verkaufen. Obwohl es jeder könnte in der Theorie Laden Sie einfach das Plugin herunter und laden Sie es auf eine öffentliche Website hoch, von der jeder es herunterladen kann. in der Praxis Niemand möchte eine inoffizielle Version verwenden, die nicht unbedingt für neue Versionen von WordPress aktualisiert wird. Der Verkauf von Plugins scheint also auch ohne jeglichen Schutz ein tragfähiges Geschäftsmodell zu sein.

All dies setzt natürlich voraus, dass jemand Ihr Plugin nicht einfach forkt und die Codebasis separat weiterpfleget. Dagegen kannst du nicht viel machen – aber es ist unwahrscheinlich, dass es passiert.

Wenn Sie versuchen, jemandem das Leben schwer zu machen, der beschließt, Ihr Plugin weiterzuverbreiten, sollten Sie Folgendes in Betracht ziehen:

• Sie können weiterhin Markenrechte für den Namen Ihres Plugins beanspruchen, auch wenn das Plugin selbst Open Source ist, sodass Sie sie rechtlich daran hindern können, denselben Namen zu verwenden, den Ihre Kunden kennen
• nur der PHP-Code in einem Plugin muss GPL-geschützt sein – Sie können alle Dateien, die kein PHP enthalten, das mit WordPress interagiert, unter einer separaten Lizenz verteilen, um die Weiterverteilung zu verbieten. Beispielsweise müssen CSS, JavaScript und Bilder nicht unter der GPL stehen.

Einen großartigen Artikel finden Sie hier, obwohl dieser nicht die Technik abdeckt, nur etwas, das Sie im Hinterkopf behalten sollten, bevor Sie die Route viel weiter verfolgen
http://www.littlehart.net/atthekeyboard/2007/07/20/protecting-your-php-code/

Verwenden Sie für eine direktere Antwort auf Ihre Frage ein API-Schlüsselsystem und codieren Sie dann Ihr PHP mit etwas in der Art von Zend Guard, damit der Benutzer nicht einfach hineingehen und die API-Schlüsselprüfung entfernen kann, während der Code codiert ist.

Die Verwendung eines API-Schlüssels ist wahrscheinlich in Ordnung. Sie müssen sich keine Sorgen machen, dass Leute Ihr Plugin raubkopieren, denn es wird passieren, egal was Sie tun. Jemand mit dem Wissen, Ihre API-Prüfung zu entfernen, ist schlau genug, um jede Art von Schutz zu entfernen, den Sie in Ihr Skript eingebaut haben. Sie können sich um diese Leute keine Sorgen machen.

Die Verwendung von Produkten wie Zend Guard ist keine Option. Es erfordert, dass der Endbenutzer Zend Optimizer auf seinem System installiert hat, und Sie können das nicht garantieren.

Abgesehen davon können Sie Ihren Quellcode sowieso nicht verschleiern oder anderweitig verbergen. WordPress ist unter der GPL-Lizenz lizenziert, und sie verbieten Plug-ins strengstens jede andere Lizenz. Während Sie das Plugin verkaufen können, können Sie den Quellcode nicht verbergen.

Um ehrlich zu sein, glaube ich nicht, dass es einen kugelsicheren Beweis gibt, um zu verhindern, dass Ihr Plugin auf Null gesetzt wird. Schauen Sie sich WProbot an, sie haben eine ziemlich solide Methode, um die Lizenzierung zu validieren, aber es gibt immer noch Hunderte von Versionen mit Nullabgleich.

Solange die Leute Ihren Code herunterladen müssen, wird jemand hineingreifen und ihn auf Null setzen. Was Sie tun können, ist, eine Fremium-Version anzubieten, wie es s2member und das AllinOneSEO-Paket tun.

Ich denke wirklich über diese nach. Aber es ist GPL und wir können unsere Codes nicht verstecken. Ich denke, wir müssen es komplizierter machen, das API-Schlüsselsystem zu lesen. Ich denke daran, dies zu tun. Aber es gibt eine Möglichkeit, dies mit remove if else system unglücklicherweise zu knacken, wenn es Open Source ist. Sie könnten zum Beispiel so aussehen: PHP AES verschlüsseln / entschlüsseln