Welcome toVigges Developer Community-Open, Learning,Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
330 views
in Technique[技术] by (71.8m points)

如何安全的完成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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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

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

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

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to Vigges Developer Community for programmer and developer-Open, Learning and Share
...