如何保护我的插件,以便只有付费用户才能使用它?

发布于 2024-09-28 18:24:10 字数 399 浏览 10 评论 0原文

我正在开发一些(wordpress)插件,并且我计划为任何想要使用它的人收取许可费。

因此,我需要一种方法来确保该插件不会上传到任何人都可以免费下载和使用的服务器。

所以我正在考虑使用 API 密钥。有效的 API 密钥 = 用户可以使用该插件。无效 = 插件不起作用。

我看过这篇文章 PHP API Key Generator 但我并没有得到更多的了解那。

我还知道,由于它是 PHP,任何人都可以进入代码并禁用 API 检查(我只是猜测)

保护我的插件的最佳方法是什么? API 密钥?其他方式?有人有关于这个主题的任何好的教程的链接吗?

I'm developing some (wordpress) plugins and I'm planning to have a license fee for whoever want's to use it.

Therefor I need a way to make sure that this plugin is not uploaded to a server where anyone can download it and use it for free.

So I was thinking of using an API key. Valid API key = user can use the plugin. Invalid = plugin does not work.

I've looked at this post PHP API Key Generator but I don't get much wiser of that.

I also know that since it's PHP, anyone can go into the code and disable API check (I'm just guessing)

What is the best way to secure my plugin? API key? Other ways? Does anyone have link to any good tutorials on the subject?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

红ご颜醉 2024-10-05 18:24:10

如果您的插件依赖与您自己的服务器的交互,API 密钥是防止非付费用户使用它的绝佳方法。
但是,如果它不需要与您的服务器交互,那么任何有一点 PHP 知识的人都可以修改您的插件以删除 API 密钥检查。

这里的一个主要问题是插件的许可。 WordPress 是 GPL,GPL 有一个条款要求“衍生作品”也必须根据 GPL 获得许可。 (这是轻描淡写的说法:事实上,整个 GPL 都是基于该条款的,没有它就无法真正工作。)
关于插件是否可以被视为“衍生作品”存在很多争论。在我看来,事实并非如此,而且我认为试图强迫它被视为一种是不道德的。然而,WordPress 核心开发者 Automattic 和自由软件基金会(编写 GPL 的组织)声称 WordPress 插件在法律上必须使用 GPL,并且不得使用其他许可证。
到目前为止,还没有法庭案件,因此没有先例,但围绕几个不使用 GPL 的主要 WordPress 插件存在相当大的敌意,Automattic 基本上威胁要采取法律行动,而插件开发者则表示“请告我”。这并不完全是一个美好的情况,我想说的是,无论情况的道德如何,事实是负面宣传通常超过了封闭源插件的好处。

总结一下:您的插件基本上必须是 GPL,这意味着您必须提供未加密的源代码,因此任何人都可以修改您的插件以删除您添加的任何限制。但是,您应该很容易说服大多数潜在客户想要从您那里购买该插件,而不是使用分叉版本 - 您可以提供支持、升级等可能无法获得的好处。 “破解”版本。

有几家公司在 GPL 下成功销售插件,并且没有任何保护(API 密钥等)。尽管理论上任何人都可以下载该插件并将其上传到任何人都可以下载的公共网站,但实际上没有人愿意使用非官方版本,因为它不会“不一定要针对新版本的 WordPress 进行更新。因此,即使没有任何形式的保护,销售插件似乎也是一种可行的商业模式。

当然,所有这一切都假设有人不只是分叉你的插件并继续单独维护代码库。对此你无能为力——但这不太可能发生。

无论如何,如果您想让决定重新分发您的插件的人过得不好,您可能需要考虑以下事项:

  • 您仍然可以对您的插件名称主张商标权,即使该插件它本身是开源的,因此您可以合法地阻止他们使用您的客户知道的相同名称
  • 只有插件中的 PHP 代码必须是 GPL - 您可以分发任何不包含交互的 PHP 的文件与 WordPress 一起使用单独的许可证以禁止重新分发。例如,CSS、JavaScript 和图像不必遵守 GPL。

If your plugin relies upon interaction with your own server an API key is an excellent way to prevent non-paying users from using it.
However if it doesn't need to interact with your server then anyone with a little PHP knowledge can modify your plugin to remove the API key check.

A major issue here is the licensing for your plugin. WordPress is GPL, and the GPL has a clause which requires 'derivative works' to also be licensed under the GPL. (That's an understatement: in fact, the whole GPL is based around that clause and wouldn't really work without it.)
There is a lot of argument about whether a plugin can be considered to be a 'derivative work'. In my opinion it isn't, and I think it is unethical to try to force it to be seen as one. However Automattic, the core WordPress devs, and the Free Software Foundation (the organisation which wrote the GPL) claim that WordPress plugins are legally bound to use the GPL and may not use another license.
So far there have been no court cases and so there is no precedent, but there is considerable animosity surrounding a couple of major WordPress plugins which don't use the GPL, and Automattic has basically threatened legal action whilst the plugin developer has said "please sue me". Not exactly a pretty situation, and I would say that regardless of the morality of the situation the fact is that the negative publicity normally outweighs the benefits of closed-sourcing a plugin.

To summarise: your plugin basically has to be GPL, which means you have to provide unencrypted source code, so anyone can modify your plugin to remove any restrictions you add. But it should be easy for you to talk most of your potential customers into wanting to buy the plugin from you instead of using a forked version - you can offer benefits such as support, upgrades, etc etc which probably won't be available for a "cracked" version.

There are several companies which successfully sell plugins, under the GPL and with no protection (API key etc). Even though anyone could in theory just download the plugin and upload it to a public site from which anyone could download it, in practice nobody wants to use an unofficial version which won't necessarily be updated for new versions of WordPress. So selling plugins does seem to be a viable business model even without protection of any kind.

Of course, all this assumes that someone doesn't just fork your plugin and carry on maintaining the codebase separately. There's not much you can do about that - but it's unlikely to happen.

For what it's worth, if you're trying to make life hard for someone who decides to redistribute your plugin, you may like to consider the following :

  • you can still claim trademark rights on the name of your plugin even if the plugin itself is open source, so you can legally prevent them from using the same name which your customers know
  • only the PHP code in a plugin has to be GPL'ed - you can distribute any files which don't contain PHP which interacts with WordPress under a separate license to forbid redistribution. For example, CSS, JavaScript, and images don't have to be under the GPL.
夜声 2024-10-05 18:24:10

可以在这里找到一篇很棒的文章,尽管这并不涵盖技术,只是在您进一步探索该路线之前需要牢记的一些事情
http://www.littlehart.net/atthekeyboard/ 2007/07/20/protecting-your-php-code/

虽然为了更直接地回答您的问题,请使用 API 密钥系统,然后使用类似于 Zend Guard 的方式对 PHP 进行编码,因此用户当代码被编码时,不能只是进去并删除 API 密钥检查。

A great article can be found here, although this doesn't cover technique just somethings to bare in mind before you pursue the route much further
http://www.littlehart.net/atthekeyboard/2007/07/20/protecting-your-php-code/

Although for a more direct answer to your question, use an API key system and then encode your PHP using something along the lines of Zend Guard, so the user can't just go in and remove the API key check as the code is encoded.

め可乐爱微笑 2024-10-05 18:24:10

使用 API 密钥可能没问题。您不必担心人们盗用您的插件,因为无论您做什么,这种情况都会发生。懂得删除 API 检查的人足够聪明,可以删除您在脚本中添加的任何类型的保护。你不用担心这些人。

使用 Zend Guard 之类的产品不是一个选择。它要求最终用户在其系统上安装 Zend Optimizer,但您无法保证这一点。

话虽如此,无论如何你都不能混淆或隐藏你的源代码。 Wordpress 根据 GPL 许可证获得许可,并且严格禁止插件拥有任何其他许可证。虽然您可以出售插件,但无法隐藏源代码。

Using an API key is probably fine. You can't worry about people pirating your plugin, because it will happen no matter what you do. Someone with the knowledge to remove your API check is smart enough to remove any kind of protection you put in your script. You can't worry about these people.

Using products like Zend Guard isn't an option. It requires the end user to have Zend Optimizer installed on their system, and you can't guarantee that.

All that being said, you can't obfuscate or otherwise hide your source code anyway. Wordpress is licensed under the GPL license, and they strictly forbid plugins from having any other license. While you can sell the plugin, you can't hide the source code.

一曲琵琶半遮面シ 2024-10-05 18:24:10

说实话,我不认为有一个万能的方法可以避免你的插件被无效,看看 WProbot,他们有一个非常可靠的方法来验证许可,但仍然有数百个无效版本。

只要人们必须下载你的代码,就会有人介入并取消它,你能做的就是提供一个免费版本,就像 s2member 和 AllinOneSEO pack 所做的那样。

to be honest, i don't think there is a bullet proof to avoid your plugin to get nulled, look at WProbot, they have a pretty solid way to validate licensing but still there are hundreds of nulled versions.

as long as people have to download your code someone will get his hands into it and nulled it, what you can do is offer a fremium version like s2member and AllinOneSEO pack does.

旧伤还要旧人安 2024-10-05 18:24:10

我真的在想这些。
但它是 GPL,我们无法隐藏我们的代码。
我认为,我们必须做更复杂的读取api密钥系统。我正在考虑这样做。但不幸的是,如果它是开源的,那么有一种方法可以通过删除 if else 系统来解决这个问题。你可以看看这样的例子:
PHP AES 加密/解密

I'm really thinking about these.
But It'S GPL and we cannot hide our codes.
I think, we have to do more complicated to read api key system. I'm thinking to do this. But there is a way to crack this with remove if else system unfortunetly if it's open source. You could look for example this:
PHP AES encrypt / decrypt

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文