spring - 如何安全的完成DTO转Domain, 主要是安全哦, 我有3个方案还有别的吗

问题描述

问 题

例如

在做更新用户信息的时候, controller 接收 UserDTO, 然后调用 BeanCopy 相关方法, 将 UserDTO 转换成为真正的 User 对象, 方式就是若属性名字相同就copy, 然后再server中执行更新用户操作

那么如果不怀好意的用户在前台传递了一个 password 参数, 那么当 dto -> domain 的时候, User 的 password 就被赋值了, 之后 Mybatis 的动态SQL就错误的拼接上了 set password = :password , 然后就用户密码就被篡改了

目前我有几种方案, 不知还有没有更加优雅的

方案1: 为该功能单独设计一个 DTO 对象, 其中只保留接口相关的属性, 这样dto中就去掉了password属性, 好处就是从源头上把控了, 缺点就是有可能DTO会非常多

方案2: mybatis的sql语句单独写一个用户更新的sql, 把拼接passowrd那一行删掉, 好处就是dto不用改, 用一个统一的dto就全搞定了, 缺点就是要单独写一个sql语句, 不能使用统一的动态sql了, 有可能sql会越来越多

方案3: 在beancopy部分下功夫, 单独写一个更新用户的beancopy, 只copy该功能相关的属性, 缺点就是有可能会写很多定制的copy方法

大家有什么建议?? 我倾向于 方案1, 建立多个DTO

解决方案

第一种方式最好，一个类应该只包含其所需要的属性。

DTO多其实无所谓，在你的场景里DTO对应的是UI。从需求层面上来讲，UI变动是比较频繁的，DTO作为一个轻量的类，为不同UI设计不同的DTO是很正常的，而且这样一来，代码修改所带来的影响面就只停留在表现层，而不是领域层。

你的第二个方法，属于将UI的需求影响到了数据存储逻辑的底层，这个是不对的。

你的第三个方法，属于将UI的需求影响到了底层第三方框架，如果哪天你换了框架就麻烦了，而且底层代码和表现层脱离，不易于理解。

这篇关于spring - 如何安全的完成DTO转Domain, 主要是安全哦, 我有3个方案还有别的吗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！