Java 具有不易修改的动态特性

快速背景：我正在设计许可证系统的某些方面。主应用程序可以被认为是一个客户端“门户”，我们将在多个环境/客户端等中安装多个版本的“应用程序”

验证许可证的过程每天都会发生：客户端应用程序将向中央授权服务器发送一些数据，以检查许可证是否仍然有效。这也提供了一种从我们的终端将许可证列入黑名单或撤销的方法

我知道硬编码凭证是个坏主意，这就是为什么我计划让这个REST“验证”步骤未经验证的原因。当涉及到URL时，我试图找出如何使其灵活，同时不让用户访问它

如果我把URL放在某个属性文件中，如果用户可以操作该文件，他们就可以找到绕过/劫持每日许可证健康检查的方法。但是通过锁定URL，它使得更改变得更加困难（需要向客户端推送代码来更新URL），这似乎也是个坏主意

---

有没有一种方法或模式可以让像这样的URL变得灵活、易于更改，但仍然安全并锁定到只有我的团队才能在URL更改时对其进行编辑？同样的问题也适用于任何可能发生更改但仍需要应用某种锁定以防止用户篡改的属性。

我可以想出各种方法：

• 存储普通URL和散列（使用秘密盐），以便知道有人篡改URL

• 存储URL的加密版本

---

但我认为更重要的是你使用的许可协议。无论URL指向何处，您仍然可以通过添加主机条目来转移请求，因此我认为还需要做更多的工作。

我不确定他们为什么要更改属性文件中的URL。这将禁用他们的应用程序-因为他们将无法访问您的服务器以验证其许可证。此外，可能有一个中心URL，所有用户首先联系该URL，然后应用程序将提供一个新的动态变化的验证服务器URL，也许？@jnbender我担心的是，他们是否找到了一些方法来创建一个模仿我们的快速应用程序，能够将URL指向该服务器以欺骗验证。另一个担忧是离线的客户（即安全政府），他们根本没有访问权限。离线客户完全改变了模式。@jnbender是的，我知道，这是我必须解决的另一个问题；）使用Java的密钥对工具。让用户向您发送一些特定于机器的信息，在您这边生成带有特定种子的公钥/私钥，向他们发送公钥（？）并让您的所有应用验证同一种子。这可能也很复杂。嘿，伙计，我在想！难道“秘密”散列和盐不会被硬编码到某种程度上吗？此外，如果一个指向某个服务的URL很容易转移（通过您提到的主机），您是否可以想出一种更安全、更高效的方法来处理客户端和授权服务器之间的来回切换？所有措施都可以规避。这取决于投入的资源。问题是你（或你的公司）愿意投资多少。同样重要的是，要考虑对购买许可证的软件用户的后果。很多人可能不高兴知道你的软件每次启动时都会“打电话回家”。此外，如果在internet连接丢失的情况下软件无法工作，您的客户是否可以接受？在保护您的权利和不吓跑潜在客户之间，可能很难找到正确的折衷方案。