杂记---Mongo的Invalid BSON field name $gte

Posted 2020-11-20 lighten

1.前言

　　这几天使用mongo的时候遇到了一个异常：Invalid BSON field name $gte，该问题可能会有很多小伙伴会遇到，因此记录一下解决过程。起因是用JAVA翻译一个其他语言写的程序，需要在mongo中保存某次的查询条件，以便下次使用。但是保存的时候抛出了这个异常，原程序却没有问题，这个肯定和JAVA的实现有关，与mongo服务本身关系不大了。下面是一个简略的排查过程，纯文字，尽量会写的简洁些。

2.排查过程

　　1.定位异常抛出的位置：

　　　　该异常由AbstractBsonWriter的writeName方法抛出，其由FieldNameValidator进行校验，校验不通过就会抛出该异常。

　　　　分析：这个过程十有八九就是用于校验mongo的键名称了，作用应该和防止SQL注入一样，用于防止命令注入的。这个时候就要明确，这个不是mongo本身限制的，而是Java的mongo driver限制的，不然没道理其他语言能够插入。

　　2.确定FieldNameValidator的规则：

　　　　该接口有四个实现类：

　　　　　　CollectibleDocumentFieldNameValidator：为空，包含.，以$开头非$db,$ref,$id校验失败

　　　　　　MappedFieldNameValidator：由其内部持有的FieldNameValidator对象决定相关校验规则

　　　　　　NoOpFieldNameValidator：不校验，直接返回true

　　　　　　UpdateFieldNameValidator：$开头的返回true

　　　　分析：这些实现类中，$gte唯一可能失败的就是CollectibleDocumentFieldNameValidator了，这个时候猜测是不是由于某些原因，选择生成错了validator，毕竟应该通过才对，或者是我插入的数据没有满足相关规则，这个可能性很低，还是因为有成功的例子。

　　3.排查CollectibleDocumentFieldNameValidator生成过程：

　　　　通过错误堆栈信息，可以逆推执行链：1.AbstractBsonWriter实际的对象是BsonBinaryWriter类，其在CommandMessage类的133行encodeMessageBodyWithMetadata方法中，通过new创建，携带了CommandMessage的payloadFieldNameValidator。2.CommandMessage是在CommandProtocolImpl类的80行调用了getCommandMessage方法，这个validator来自CommandProtocolImpl的payloadFieldNameValidator字段。3.CommandProtocolImpl是由DefaultServerConnection的command的方法中new创建而来的，第127行。payloadFieldNameValidator是作为参数传递过来的。4.参数由MixedBulkWriteOperation的executeCommand传递，调用的方法是BulkWriteBatch的getFieldNameValidator方法获得，该方法具体内容如下：

 

　　可以看到其是根据batchType来进行操作的，这个值怎么来的这里不再多说明，但是很显然我们是要做一个插入操作，除非有bug，不然此处的batchType应该是INSERT。这样就清楚了为什么抛出了这个异常，原因都在于这里生成的校验器是CollectibleDocumentFieldNameValidator。

　　4.知道了原因，但是如何解决呢？

　　　　第一个思路是能不能不走那个逻辑，即不走writeMap方法。通过断点发现对象的所有字段都转成了BsonString类，只有那个是map，查看基础体系发现其继承自BsonValue, BsonValue有个实现类BsonDocument，是不是要用这个类可以绕过writeMap方法呢？实际上是不行的，这个类也是一个map对象。

　　　　第二个思路在查询代码中看到了MixedBulkWriteOperation类有一个bypassDocumentValidation属性，这个是不是有什么关系呢？蛋疼的是mongoTemplate.insert方法不能设置这个属性，必须通过getCollection.insert可以通过传入InsertOneOptions进行设置。实际上这个也没用，其含义是：绕过设置的校验规则，插入数据。但是这个是针对mongo而言，现在在Java的driver层就over了，这个属性在这里没有太多作用。

　　5.陷入了死局，借助网络的力量，来看看其他人的解决思路。

　　　　常见做法：替换掉$符号，用＄来绕过验证，使用的时候再换回来。这样做确实有效，但是在多系统公用一个数据库的情况下，让所有模块都取出来的时候替换回去无疑是一个很麻烦的做法。

　　６.意外收获：

　　　　查询过程中，突然发现mongo在3.6版本之前都是不能插入$等特殊字符的，心中一凉，但是我用的是高版本的，而且有成功的例子，这个应该不是主要原因。

　　　　后来又查到另一个人的解决方法是重写了driver的部分代码，替换了那部分校验逻辑。但是这无疑是一个比较麻烦的操作，而且难保不出现什么问题。

　　　　最后找到了 https://jira.mongodb.org/browse/JAVA-2810。这特么是个Java版本的driver的bug，没有跟上服务端的版本更新，毕竟3.6之前还是不允许的，所以一直遗留到现在，该任务至今还是Unresolved状态。

　　7.如何解决：

　　　　确定这个是一个未来得及同步服务端特性的bug之后，之前的排查就没有意义了，通过API接口是无法解决的了。那么到底怎么做呢？替换掉字符，代价太大，重写driver很难保证是否有其他坑，有风险。有没有最小代价解决该问题的方法。回顾CollectibleDocumentFieldNameValidator，其并不是所有的$开头的都禁止了，不是有三个放行了吗。这个是用私有静态常量的List完成的，第一个反应就是扩大不校验的区间。如何扩大？通过反射。主要代码如下：

Field field = CollectibleDocumentFieldNameValidator.class.getDeclaredField("EXCEPTIONS");
field.setAccessible(true);

Field modifiers = Field.class.getDeclaredField("modifiers");
modifiers.setAccessible(true);
modifiers.setInt(field, field.getModifiers() & ~Modifier.FINAL);

List<String> newValue = Arrays.asList("$db","$ref","$id","$gte");
field.set(null, newValue);

　　8.验证问题解决。

3.后记

　　该问题是mongo driver的一个bug，官方暂时未修复，需要自己想办法解决，此文给出了三种解决思路：

　　　　1.替换字符，查询的时候替换回来。如果读写分离且涉及多个程序，该方法就比较麻烦了，但是最安全。

　　　　2.重写mongo driver修复这个bug。风险过大，未完全了解driver的运行，修改出未知问题也是可能的。

　　　　3.通过反射，扩大$开头的放行字段。这个是用于防止注入攻击的，所以会产生相关风险，但是自己代码中控制好就没有太大问题。另一个缺点是如果是包含.的字段这种手段就没有效果了。

　　这三种方法根据个人需要进行调整。最后如果官方修复了这个问题，还是及时更新jar包才是上策。这一点要牢记。