日常开发中注意点总结（一）

对于更新的功能，在开发的时候，需要注意一些内容

问题一：举例子：对于应付结算单修改页面中那些不支持修改的内容，我在前台通过点击按钮调用一次更新方法，不能被更新，即使在前台页面中是有限制不能修改， 但是如果通过F12，是可以拿到请求url、请求参数的，如果此时如果通过F12，将url请求重发一下，并手动将不能修改的字段修改了，再发送，那后台如果用的是mybatisplus的updateById的话，就会把所有传过来 非空的字段进行更新。这样就会产生不能修改的字段可以 被修改了。可以会造成不必要的麻烦或者损失。 那针对于这种问题，我们如何去解决呢 ？

（1）方式一：对于后台接收修改入参的实体VO中，仅仅有那些可以修改的字段，不包含不能被修改的字段，这样即使前台再怎么模拟请求，修改参数，对于不能修改的字段也是无法修改的，这种情况就无法修改的字段 就避免了通过其他方式的修改了，那对于可以修改的字段，也不能说里面的值是可以任意修改的，比如下拉框那种向后台传枚举值的，从前台页面点击的话，自然是有限制，只能传输那些固定合法的枚举值， 但是如果通过F12，修改这些字段再发请求也是能被修改的，所以为了增强程序对这种类型字段的安全性限制，就需要在后台通过自定义注解或者业务代码的校验，来校验这些字段的变化是否合理，合理才能被修改 不能只要发过来请求就被修改，这样会保证这些枚举值字段的安全性（这个还包含于那种级联下拉框的选择，比如我选择完第一个之后，第二个只能选择固定的一些，这种也可以在后台通过业务进行限制； 还包含那种本身就带有金额校验的那些字段，在更新的时候也是得校验的，不能前台传什么就存什么），这个最后就还可以通过mybatisplus的updateById进行更新数据库操作，这样是问题不大的，因为限制都在前面加了

（2）方式二：对于后台接收的修改的入参实体中包含该页面的所有字段（因为有很多代码生成器，对某个实体的生成的话，肯定是生成了所有的字段，此时VO里面就有页面的所有字段了），此时就像第一种方式一样，对那些枚举字段或者 金额字段该加的校验还是要加的，但是最后就不能直接使用 mybatisplus的updateById这个方法了，因为还使用这方法的话，如果请求中的参数是通过F12的方式传参，并在F12中模拟请求，已经将不能修改的参数修改了， 此时再直接用updateById（实体）进行修改的话，就会把不能修改的字段也给修改了，这也会有很大的问题，所以对于这种入参VO中包含所有参数的，需要在操作数据库的时候，自己去写update方法，仅仅根据需要更新 的那些字段是否为空，来更新那些能修改的字段，形如这种的sql update table set A =? ,B =? ,C=? where id =?这种的； 其中后面都是本就可以更新的那些字段

 

但是这两个方式也会有限制：

对于那种用户直接填写的字段，只是作为展示的，无法在业务代码、自定义注解中进行校验的，还是可以被不法分子通过F12 进行任意修改的，这种通过上述两种方式是无法避免的 这种就得通过判断请求是从哪个域名请求过来的，去拦截了，这就是更深一个层次的内容了，因为从浏览器登录账号页面操作的，那种是从固有的域名下发送的，但是对于不法分子，通过各种手段，拿到请求rul及入参，肯定是 通过其他工具进行请求，这种可能就不是从这个域名过来的了，这种的请求就可以被拦截。这种就能避免那种问题 了