跳至主要內容
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?

4563博客

全新的繁體中文 WordPress 網站
  • 首頁
  • 一个可能长期存在,但是不被注意,可能没有发生问题,但是存在隐患的问题
未分類
10 9 月 2020

一个可能长期存在,但是不被注意,可能没有发生问题,但是存在隐患的问题

一个可能长期存在,但是不被注意,可能没有发生问题,但是存在隐患的问题

資深大佬 : Cbdy 4

最近看别人的代码,发现服务端的接口直接把数据库的实体传给了前端,这可能会导致一些隐患。

问题

比如某实体定义如下

data class LogEntity(         val id: Long,         val desc: String )  val logEntity = LogEntity(id = 122337203685400001L, desc = "Some description") 

转成 JSON 变成了

{   "id":122337203685400001,   "desc":"Some description" } 

然后前端把这个 JSON parse 成 JavaScript 对象,变成了

Object { id: 122337203685400000, desc: "Some description" } 

LogEntity 的 ID 个位的 1 变成了 0,出现问题了。

这实际上是一个 JavaScript 的number类型处理数字的 feature,JavaScript 能准确表示-2^53到2^53之间的整数,具体可以看这个文章。然而有的语言的 Long 类型的范围是大于-2^53到2^53这个范围的,比如 Java 的Long的范围为-2^63到2^63-1,而在数据库里定义有符号的BIGINT,往往会用Long来在应用内存中表示。(当然实际实践中这么大的数字可能比较少见。)

所以比较合适的做法是在定义一个用于传输数据到前端的 DTO,把Long转成 JSON 支持的string类型,如

data class LogDTO(         val id: String,         val orderDesc: String )  val logDTO = LogDTO(id = logEntity.id.toString(), desc = logEntity.desc) // {"id":"122337203685400001","desc":"Some description"} 

结论

在实践中使用专门定义的 DTO 传输数据确实是一个比较好的做法。除了上述的问题,其他的如 JSON 不支持时间,可以用 ISO8601 字符串或 UNIX 时间戳,JSON 不支持byte[],可以编码成 Base64 。

所以请不要直接向前端返回定义的用于 CURD 的数据库实体。

大佬有話說 (2)

  • 資深大佬 : sunjiayao

    更大的问题是数据泄露。

  • 資深大佬 : kop1989

    暴露给公网的 api 返回的一定得是针对 api 本身业务内容设计的 vo 也好,dto 也罢。
    因为没必要暴露全部的 domain 字段。

    至于说类型方面的序列化 /反序列化问题,谁做都行。
    后端可以针对性转换,前端也可以。

文章導覽

上一篇文章
下一篇文章

AD

其他操作

  • 登入
  • 訂閱網站內容的資訊提供
  • 訂閱留言的資訊提供
  • WordPress.org 台灣繁體中文

51la

4563博客

全新的繁體中文 WordPress 網站
返回頂端
本站採用 WordPress 建置 | 佈景主題採用 GretaThemes 所設計的 Memory
4563博客
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?
在這裡新增小工具