ASP.NET - 阻止应用程序使用的最佳方法是什么?

发布于 2024-08-22 23:11:10 字数 645 浏览 3 评论 0原文

我们的客户必须每月支付费用...如果他们不这样做,阻止 asp.net 软件使用的最佳方法是什么? 注意:应用程序在客户端自己的服务器上运行,它不是 SaaS 应用程序...

我的想法是:

想法:在互联网上托管一个 Web 服务,应用程序将使用该服务来了解客户端是否可以使用该软件。 问题 1 - 如果客户端互联网出现故障怎么办?或者数据中心出现故障? 可能的答案:让每个Web服务访问发送一个有效期为7或15天的密钥,因此每次Web服务咨询将使软件运行更多7或15天,这样应用程序将仅在 7 或 15 天后锁定,无需咨询我们的网络服务。 问题 2 - 如果客户端没有或不想启用对应用程序的互联网访问?

想法 2:每月向客户发送一个密钥。 问题 - 如何制作离线密钥? 可能的答案:使用“限制”日期生成哈希,因此每次登录尝试软件都会将今天的哈希与密钥进行比较? 问题 2 - 在哪里存储密钥? 可能的答案:数据库(不好,太容易改变),文本文件,注册表,代码文件,程序集......

任何意见将不胜感激!

Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...

My ideas are:

Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?

Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...

Any opinion will be very appreciated!

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

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

发布评论

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

评论(5

囍孤女 2024-08-29 23:11:10

啊,DRM 的老问题了。这就是你在这里所说的。坦率地说,你的问题的根本答案是:你不能。无论您对系统做什么,它都可能被黑客攻击和修改,从而绕过和/或破坏您的 DRM 身份验证方案。

这是软件开发的一个基本事实:它可以而且将会被盗版。

因此,您问题的答案是,您必须相信客户会向您支付您认为正确的费用(这是这种情况下合同的全部要点)。

您采取的任何其他行动都会给您的付费客户带来困难和烦恼,并有可能侵蚀您的客户群。

现在,如果您希望按照所描述的性质控制您的软件,那么请勿将其提供给用户以在他们自己的服务器上运行。迫使他们成为 SaaS。这样,你就可以控制这一切。但这是唯一的办法。

您似乎没有考虑到这一点,但我看到网络不允许任何类型的“拨号回家”解决方案,因为大多数系统都集中在内部,因此不允许这些内部服务器联系外部互联网。完全没有。即使允许他们访问也被认为存在安全风险。您将如何处理这些网络?

坦率地说,如果我是客户,并且我支付了费用来许可您的软件(我安装在自己的设备上),如果我必须允许该设备访问互联网才能使其工作,我会很生气。更重要的是,如果所讨论的软件是任何类型的财务管理、客户管理、人力资源管理、质量管理、库存管理、销售,或者只是与我的业务、客户或员工相关的任何内容。当我的业务相关数据保存在他们的软件中时,我不太信任软件开发人员让他们的软件与其他东西对话。

最后,您所描述的是对您的付费客户采取的对抗性方法。如果您不相信我,请看看育碧对其最新的客户讨厌的 DRM 方案所收到的评论。

IMO,你在这里有两条好的途径:

  1. 使用 SaaS
  2. 确保你的合同有一个
    因不付款而被咬

Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.

This is a fundamental fact of software development: it can and will be pirated.

So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).

Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.

Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.

Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?

Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.

In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.

IMO, you have two good paths here:

  1. Go SaaS
  2. Ensure your contract has a
    bite for non-payment
入画浅相思 2024-08-29 23:11:10

通常,您会提供一个加扰密钥,其中包括有效的授权令牌以及支付服务费用的到期日期。然后安装程序将使用它来“激活”您的软件。不知道如果您有 1-2 周的月经周期,您会如何看待这一点。您想警告他们即将到期。也不知道如何判断他们是否已将自己的时钟调​​慢。

简而言之,没有什么是完美的。

usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.

In short, nothing will be perfect.

花桑 2024-08-29 23:11:10

我以前处理过这个问题,但不可能建立一个完美的系统。你所做的任何事都有风险。最好的办法是权衡您的选择,并确定最不可能被黑客攻击以及最有可能为客户正确、轻松地工作的方法。

正如其他人所说,他们可以改变时钟并使许可证检查机制失效。如果您不信任该用户,您可以让许可证系统连接到您的服务器。然后,您需要确保他们始终连接到您的服务器以检查许可证。

如果他们有正当理由无法访问您的服务器怎么办?

  • 他们的互联网连接有问题。
  • 您的互联网连接有问题。

在这种情况下,您应该禁用该应用程序吗?可能不会。但话又说回来,如果他们故意关闭连接怎么办?然后你会想要禁用该应用程序。

如果你给他们每月一次的钥匙,你就会增加每月的烦恼,并且在一段时间后你可能会失去客户(人们倾向于与那些让事情变得容易的人做生意)。

例如:如果您基于他们的时钟,并且应用程序出于某种原因需要他们的时钟准确,那么客户不太可能更改他们的时钟。

I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.

Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.

What if there is a valid reason that they cannot access your server?

  • Their internet connection has a problem.
  • YOUR internet connection has a problem.

In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.

If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).

For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.

倒带 2024-08-29 23:11:10

我同意斯蒂芬的观点,但最终,我认为你的合同是你最好的盟友。

如前所述,您不想给客户带来不便,尤其是在您有大型部署的情况下。

至于SaaS,如果我是使用你产品的客户并且你说模型正在改变我们需要从您的服务器访问该软件,而我们的服务器必须退役,我不高兴。我可能会利用这个机会更换套餐。

I agree with Stephen but ultimately, I think that your contract is your best ally here.

As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.

As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.

话少心凉 2024-08-29 23:11:10

在公司环境中,合同确实是处理这些问题的最佳方式。我曾研究过桌面和 ASP.NET 应用程序的许可问题,它们可能会给您和您的客户带来许多麻烦。

然而,如果你坚持使用这样的东西,我建议你采取中间立场。不要只解锁应用程序一两周,而是提供 6 个月或一年的许可证。这样,如果您遇到许可问题(并且您将遇到问题),它们每年只会发生一次,而不是每月发生几次。这对您来说支持成本会更低,而且您的客户对处理许可问题也不会那么不满意。如果公司停止付款并且您需要终止许可证,您可以根据需要使用合同执行一次性处理该问题。

在网络服务或客户端许可选项上,我认为一个好的许可系统应该将两者结合起来。客户端许可证为应用程序提供稳定的许可证和 Web 服务,以便在更新应用程序时生成和交付许可证密钥。如果客户端不允许应用程序回拨以获取许可证密钥,还可以提供手动输入方法。

如果您打算在客户端上存储许可证,请不要尝试自己构建组件。有许多可用的组件比您构建的组件更加坚固和可靠。有一个 基于 .NET .licx 的许可方法以及一些第三方方法< /a> 你可以使用。哪一种最合适取决于您的情况:您想要许可证的灵活性以及您需要哪些其他选项。最重要的是,找到可靠的东西 - 任何时候您的客户花时间解决由许可引起的问题对他们来说都是没有生产力的,并且会给应用程序带来不好的影响。

需要记住的重要一点是,没有任何系统是万无一失的。如果您的应用程序有价值,就会有人想出如何窃取它。但在企业层面和定制软件中,许可更有可能被用来提醒人们付费,而不是阻止大规模盗版。

In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.

However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.

On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.

If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.

The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.

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