我有一个包含 10 个功能的桌面应用程序,有些客户只要求 8 个功能或 7 个功能。我想有一种方法来管理添加/删除客户端的权限/功能(只有我可以控制)。这样我就可以根据标志隐藏/显示功能。
这应该通过一个包含带有布尔标志的功能名称的属性文件来完成,还是什么?
请给我一些想法,谢谢。
我有一个包含 10 个功能的桌面应用程序,有些客户只要求 8 个功能或 7 个功能。我想有一种方法来管理添加/删除客户端的权限/功能(只有我可以控制)。这样我就可以根据标志隐藏/显示功能。
这应该通过一个包含带有布尔标志的功能名称的属性文件来完成,还是什么?
请给我一些想法,谢谢。
从您的其他答案中,我觉得出现了以下附加细节;如果我有这些错误,请告诉我:
在这种情况下,我会将“活动”功能列表存储在一个散列属性值中,该值存储在一个绑定到 .jar 的 .properties 文件中。我将在下面描述一种方法。在交付之前生成属性文件,将文件添加到 jar 中:
jar -uf applicationJarFile.jar configuration.properties
然后签署 .jar 并交付。在运行时,您的应用程序可以加载属性文件,运行每个功能的哈希,与您存储的属性进行比较,并确定哪些是关闭或打开的。
您的属性(用于确定启用哪些功能)可能包含如下列表:
feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled
为自己编写一个实用程序,它对整个字符串“feature1=enabled”加上一个盐值进行哈希处理,例如“feature1=enabledaKn087*h5^jbAS5yt”。(Java 中内置了此代码;例如,请参见How can I generate an MD5 hash? feature1=1865834.... 盐值应该在您的代码中分解成多个较短的字符串,这样您的客户就不能只检索它并轻松地自己复制该过程。
在您的应用程序中,在启动时,您使用“启用”和“禁用”值构造上面的字符串,运行两者的 MD5,并将其与存储的哈希值进行比较。这将告诉您要启用哪些功能。
我认为单独的 .jar 或 .properties 是个坏主意。它使您的交付混乱。
您可以相当轻松地自动化整个过程,因为您可以随时动态生成属性,并将它们绑定到您的应用程序中。
您可以添加其他“内置”属性,从而在最终交付中为您提供很大的灵活性,包括为客户品牌设计蒙皮之类的东西。
不过,正如其他人所指出的那样:有很多方法可以解决这个问题,具体取决于产品的其他细节和总体目标。鉴于上述假设,这是一种方法。AFAIK,没有“规范”的方式来做这种事情。
您应该考虑使用许可证管理 api 来做同样的事情,这将为您提供安全性和更改许可证前/后安装的能力。
不建议构建临时许可功能,请查看License3j和TrueLicense,它们都是免费的,可以帮助您获得观点或更好地满足您的要求
您可以尝试将其编码到文件中。我假设每个用户都有自己的应用程序安装/版本,对吧?我进一步假设应用程序不需要检查某些 Web 资源。因此,您需要在文件中实现它。
但是,您应该加密该文件并将盐和密钥放在代码中不容易被反编译的地方。另外创建一个哈希来检查文件的修改。该哈希可以基于应用程序的大小或其他内容。
请注意,没有 100% 的安全性,任何黑客仍然可以破解您的应用程序。但在那种情况下,这将需要某种形式的犯罪能量,这种能量在商业世界中并不常见。
模块化应用程序并仅将他想要/可以访问的那些部分部署到每个客户端。有很多方法可以做到(最完整但重量级的是 OSGi),但具体取决于您的情况和要求。
实现它的最快方法可能是简单地将额外功能提取到单独的 JAR 中,并在部署时适当地更新类路径。
这是非常开放的——它真的取决于你想要实现的目标,以及你所说的特性。
一种方法是使用基于插件的架构。例如你有一个界面
public interface Feature {}
并提供你的十个特性中的每一个作为这个接口的实现者。然后有一些在应用程序启动时运行的方法,它在Feature
类路径上查找子类。
您可以通过仅在类路径中包含相关功能来控制客户端具有哪些功能,例如使用 maven。
这取决于应用程序的类型、您想要的安全类型以及可能使用该应用程序的人数。
如果客户端的数量不是那么大,您可以将他们的偏好存储在一些内存数据结构中,例如 Map 。否则,您可以使用文件系统或数据库,具体取决于您想要的安全类型。