2、自己研发,但是须要部署到客户的云服务器或者私有化服务器,但是不交付源代码。这种模式有一个须要考虑的点:一旦部署到客户的云服务器或者私有化服务器,系统就变得不好管控或者说失去了控制。表现在:一旦过了条约有效期,想停掉运行在客户服务器的系统,那就变得很困难,或者对方不配合,或者对方也可以找运维职员自启动(本文先不考虑客户拿到 jar 包反编译源代码的情况,如果条约有代码协议的束缚,那就是违法的)。本篇博客重要针对这种模式做 Licence 研发,让私有化部署的系统变得可管控。
3、自己研发,资助客户部署到指定服务器,并且交付源代码。
2、研发思路
2.1 不可行的方案
1、条约束缚或者口头束缚。一样平常来说,两家公司不合作之后,基本上关系就变得淡漠或者陌路,跟你在一家公司去职的情况差不多。想要口头束缚客户别用你们之前的系统,险些不大概,只要还能用,客户也会偷偷用,实在用不了才会考虑替代方案,这是人之常情。
2、把“能用”和“不能用”的控制逻辑放在数据库或者设置文件中。这种方案也不太行,懂一点技术人会顺藤摸瓜,把他们的数据库或者设置文件看一下,哪些是重要信息,修改一下,就能继续用了。
因此,我们须要考虑一个万全之策,既能做到系统的管控,又能做到后期的简朴维护。那就是把控制逻辑嵌入到代码中(本文先不考虑客户拿到 jar 包反编译源代码的情况,如果条约有代码协议的束缚,那就是违法的)。
public class LicenceEntity implements Serializable {
private static final long serialVersionUID = -4048081970386334457L;
/**
* 证书 ID
*/
private String licenceId;
/**
* 证书名称
*/
private String licenceName;
/**
* 客户端机器的网卡物理地址
*/
private String mac;
/**
* 秘钥(指的是公钥)
*/
private String key;
/**
* 证书生效开始日期,格式:yyyy-MM-dd
*/
private String effectStartDate;
/**
* 证书生效结束日期,格式:yyyy-MM-dd
*/
private String effectEndDate;
/**
* 颁发证书联系人
*/
private String contactName;
/**
* 颁发证书人的联系方式
*/
private String contactWay;
/**
* 证书所有者
*/
private String owner;
/**
* 加密的内容。这个字段是将其它字段加密后的完整内容
*/
private String content;
}
复制代码
说明
1、mac:这是客户端的网卡物理所在,每台呆板的物理所在都不一样,基本上可以保证你们公司服务的客户是唯一的。这个 mac 所在,一样平常是负责部署的职员去获取,或者让客户自己提供。这个字段的意义在于:如果你们公司要进行严酷的证书校验,必须是一个证书只允许在一台服务器上利用,那这个字段就显得非常重要。固然,你可以换成自己喜欢的字段名。