我们开发了一个定制的 ASP.NET 应用程序，供在客户的 Intranet 上使用。
看来他们不太可能为此付出代价，所以我们的老板希望我们引入一个定时炸弹。
[编辑：] 请仅提供技术答复！这是否是一个好（或合法）想法是 CEOoverflow.com 的问题 ;-)
应用程序中的所有页面都继承自一个名为 ApplicationBasePage 的类，并且具有一致的错误处理，因此我认为在 ApplicationBasePage 生命周期的早期抛出异常将是使应用程序无法使用的简单方法。不过，我对您可能有的其他想法持开放态度。
我的问题是：我们应该如何以及在哪里存储应用程序到期的日期？
需要注意的几点：
- 该应用程序安装在客户办公室的一台服务器上。
- 应用程序数据保存在同一服务器上的 SQL Server 2005 数据库中。该数据库是我们设计的，不用于其他任何用途。
- 该应用程序只能在其 Intranet 上访问：无法通过 Internet 访问该应用程序。
- 我们目前可以通过远程桌面访问他们的服务器，但如果情况变得糟糕，我们预计会失去这种访问权限。
- 该应用程序是用 .NET 2.0 编写的。
- 安全性由 FormsAuthentication 处理。
- 我们需要能够轻松关闭定时炸弹或更改其触发日期（假设我们仍然具有远程桌面访问权限来执行此操作）。
- 服务器可以正常访问Internet，但最好不要依赖于此。
- 定时炸弹只会将用户锁定在外：它不会破坏任何数据。
- 除非它被触发，否则客户绝不能意识到定时炸弹的存在。
- 他们的 IT 人员会很乐意在 web.config 或数据库中进行研究。他不是程序员，但他并不害怕改变事情“只是为了看看会发生什么”。对应用程序进行反编译或逆向工程超出了他的能力范围。
额外加分的是，在这种情况下，您认为通过默默无闻来实现安全性的依赖程度有多少是可以的？
[Edit:]
- 该应用程序执行许多与日期相关的业务关键型操作，因此我们可以确定他们不会更改服务器上的时钟，因为这将使应用程序变得更糟。
“他们看起来不太可能为此付出代价，所以我们的老板希望我们引入一个定时炸弹。”
一位无能的商人要求您实施业务问题的技术解决方案。如果你的客户不打算付钱，你的老板应该像成年人一样处理这种情况，而不是像高中黑客一样用逻辑炸弹搞砸。
这是不道德的，可能是非法的，但大多数情况下它只是愚蠢的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
