NO.13 生产环境增量更新漏洞

知识库总目录： No.0 Web开发知识库

出于对于更新效率的要求，我们在更新生产环境时，比较多的是采用增量更新的方式：即仅将需要更新的文件打个包，在生产环境解压（一般需要重启服务）即可完成更新。
而在这个过程中有几种漏洞，不可不察。

1.内部类
对于java文件更新申请人一般提交的是源文件（即java文件）而非编译后文件，然而增量更新打包清单往往仅根据源文件清单生成而来；
但若某个源文件中存在内部类，其编译后，每个内部类会独自生成一个class文件，更新清单会将其遗漏。
因此建议由更新申请人应注明本次更新中存在内部类的java文件，由更新执行人手工修改更新清单，将内部类class文件补全
例：
A.java

import java.util.TimerTask;

public class A{
public class B{
}

public void aMethod(){
class C{
}
}

public void bMethod(){
new TimerTask() {
public void run() {
}
};
}
}

A.java中有个puclic class A，A中有个成员内部类 B,方法内部类C，还有一个匿名内部类new TimerTask()
则编译出的class文件有
A.class
A$B.class
A$1C.class
A$1.class

2.特殊配置文件
特殊配置文件即上篇中提到的生产、测试环境配置内容有差异的配置文件。
由于无论是开发环境，还是基线测试环境，这些特殊配置文件中内容都是配置的测试环境内容，当这种文件需要提交更新时，提交人一般提交的是测试版(要先发布在基线测试环境上)，而后续又将测试版发布在生产环境，后果相当严重。
此时，也建议由更新申请人应注明本次更新中存的特殊配置文件，以便执行人做后续处理。

3.常量
先看一个例子：

A.java
public final static String MESSAGE="我是常量串";

B.java
public aMethod(){
String b = A.MESSAGE;
}

原代码中B跟A有关系，不过编译后就跟A没啥关系了，B编译完后就成了这个样子:

B.class
public aMethod(){
String b = "我是常量串";
}

所以当常量内容发生变化修改了常量所在的类后，只更新这个类没有用，而是需更新所有调用类。