Java Web 应用程序基于日期的许可逻辑？
我正在尝试为 Java Web 应用程序提出基于日期的许可机制的逻辑。 该应用程序需要部署在可能无法访问 Internet 的客户端站点（部署在 Intranet 上）。 在这种情况下，如何构建基于开始/结束日期的许可机制。 如果我为此使用服务器系统日期/时间，则系统管理员可能会更改服务器日期/时间以保持许可证处于活动状态。 有什么建议么？ Windows 桌面应用程序似乎可以做到这一点，不知道如何实现？
桑杰.
I am trying to come up with a logic for a date based licensing mechanism for a Java web app. The app needs to be deployed in client sites which may not have access to the Internet (deployed on the intranet). In this case how do I build a licensing mechanism based on Start / End Dates. If I use the server system Date / Time for this, I risk the system admin changing the server date / time in order to keep the locense active.
Any suggestions? Windows dektop apps seem to do this, not sure how?
Sanjay.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，我想如果规则是： (a) 许可必须基于开始和结束日期； (b) 不能假设计算机与外界相连，那么我认为这个问题在理论上是无法解决的。 日期的唯一来源将是计算机本身的某个日期，可以是系统日期，也可以是用户输入的其他日期。 也许我错过了一些东西，但我不明白它如何不会受到用户对日期撒谎的影响。 我的意思是，如果计算机没有连接到外界，那么根据定义就没有外部来源来验证日期。 您可以像 Joeytwiddle 的建议那样对日期进行合理性检查，记录您以前见过的日期并查找任何可疑的内容，例如倒退的日期或最近 6000 次运行的同一天或其他任何内容。 除此之外，这听起来像是化圆为方或寻找诚实的政治家的问题：这是不可能完成的。
Hmm, I think if the rules are: (a) The licensing must be based on start and end dates; and (b) The computer cannot be assumed to be connected to the outside world, then I don't think the problem is even theoretically solvable. Your only source of what the date is will be some date on the computer itself, either the system date or some other date the user enters. Maybe I'm missing something, but I don't see how it could NOT be subject to the user lying about the date. I mean, if the computer is not connected to the outside world, then there is by definition no outside source to verify the date. You could do something like Joeytwiddle's suggestion to do reasonableness checks on the date, record dates you've seen before and look for anything suspicious, like the date going backward or it being the same day for the last 6000 runs or whatever. Beyond that, this sounds like a problem in squaring the circle or finding an honest politician: It just can't be done.
一个可能的解决方案：
您将定期向您的客户端发出一对匹配的密钥和一个密钥验证类。 服务器应用程序应至少在启动时或使用 JVM 时间定期检查验证类。
您还需要为客户提供一种简单的方法来获取更新的密钥/验证器更新。
归根结底，考虑到可以检查和操作 java 类文件，这仍然不是一个完整的证明机制，但它确实提供了一种不依赖于主机机制的临时许可方案。
A possible solution:
You'll periodically issue a matched pair of key and a key verify class to your clients. The server app should check with the verify class, minimally at startup, or periodically using JVM time.
You'll also need to provide your clients a trivial way to get renewed key/verifier updates.
At the end of the day, this is still not a full proof mechanism given that the java class files can be inspected and manipulated, but it does provide a temporal licensing scheme that is not dependent on host mechanisms.
通过让您的应用程序记录上次运行时间来检测系统日期的任何更改。 如果它启动后发现它是未来的最后一次运行，您可能会怀疑犯规！
当然，如果用户可以找到 lastRunDate 数字的存储位置，他们就可以绕过它。 编辑：如果用户真的注意到他的机器的日期错误并更改它，它也可能被错误触发。 如果您不使用世界时，请不要忘记夏令时更改（为有效日期更改留出一两个小时的灵活性）。
Detect any change in System Date, by having your app record the last time it was run. If it starts up and finds it was last run in the future, you can suspect foul-play!
Of course if the user can find where that lastRunDate number is stored, they can get around it. Edit: Also it can be mis-triggered if a user really notices his machine's date is wrong and changes it. If you aren't using Universal Time, don't forget about daylight-saving changes (allow an hour or two of flexibility for valid date changes).