V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mokevip
V2EX  ›  程序员

如何看待后端接口带出数据库全部字段

  •  1
     
  •   mokevip ·
    moke8 · 2022-04-13 16:10:43 +08:00 · 11043 次点击
    这是一个创建于 934 天前的主题,其中的信息可能已经有所发展或是发生改变。

    直接从数据库中取得模型,不需要的值就是一堆 null

    如果是需要额外处理的字段,就在原本对象内放一个 params 的对象,再嵌套一层放处理的数据

    能因为一个值需要转换一下数据而扯皮,哪怕是取模于 10 这种简易操作也要前端来做

    图 图

    128 条回复    2022-04-16 11:03:48 +08:00
    1  2  
    zilongzixue
        1
    zilongzixue  
       2022-04-13 16:14:00 +08:00   ❤️ 1
    null 值有什么问题,现在前端框架的表单不是自动处理 null 值的吗
    mokevip
        2
    mokevip  
    OP
       2022-04-13 16:14:51 +08:00
    mokevip
        3
    mokevip  
    OP
       2022-04-13 16:15:29 +08:00
    @zilongzixue 为什么要多出来这些数据呢?
    yedanten
        4
    yedanten  
       2022-04-13 16:17:21 +08:00 via Android   ❤️ 3
    单纯的偷懒行为,还有模型字段名和数据库字段名如果是完全一致,算是低危的信息泄露
    dicc
        5
    dicc  
       2022-04-13 16:17:23 +08:00
    你知道我爬 Twitter 什么感受不,那字段。。。
    putaozhenhaochi
        6
    putaozhenhaochi  
       2022-04-13 16:18:24 +08:00 via Android
    让后端加个 entity 转成 VO
    6IbA2bj5ip3tK49j
        7
    6IbA2bj5ip3tK49j  
       2022-04-13 16:23:27 +08:00   ❤️ 3
    后端又懒又菜。
    懒是因为用了一个巨大的万能对象应对所有接口。
    菜是让人发现这么做了。
    arthas2234
        8
    arthas2234  
       2022-04-13 16:32:04 +08:00
    null 值是可以加个配置过滤掉的,直接返回数据库字段肯定不可行
    很好奇,用户表也是这么做的吗,我看第二张图里面还有 oldPassword 这个字段,也是厉害
    cweijan
        9
    cweijan  
       2022-04-13 16:33:00 +08:00   ❤️ 1
    其实就是偷懒, 后端懒得建个 DTO, 直接返回数据库实体.
    learningman
        10
    learningman  
       2022-04-13 16:38:36 +08:00   ❤️ 3
    入侵最喜欢这种了,sql 注入的时候猜表累死人
    mokevip
        11
    mokevip  
    OP
       2022-04-13 16:40:25 +08:00
    emmm ,我因为这个问题和他们怼过无数次,我是给不了啥建议了,暂时救不了他们
    mokevip
        12
    mokevip  
    OP
       2022-04-13 16:41:54 +08:00
    @dicc 啥感受
    mokevip
        13
    mokevip  
    OP
       2022-04-13 16:42:27 +08:00
    @putaozhenhaochi 有没有文章这种,因为我是前端,对这个不太了解,后端是 JAVA 的
    mokevip
        14
    mokevip  
    OP
       2022-04-13 16:43:04 +08:00
    @arthas2234 所有的都是 = =
    lmmlwen
        15
    lmmlwen  
       2022-04-13 16:45:08 +08:00   ❤️ 1
    没时间啊,这就是最重要的,而且返回的数据结构这种东西对个人来说并无任何实际价值。我看有人说菜,这和菜没什么关系,谁不知道处理返回的资源,核心原因就是不是自己的东西不心疼
    clf
        16
    clf  
       2022-04-13 16:53:28 +08:00
    就是没写 VO 的问题。

    实在偷懒其实可以在类上加上 @JsonIgnore 这种注解就可以了。
    47d7tEUBp521E8fJ
        17
    47d7tEUBp521E8fJ  
       2022-04-13 16:53:47 +08:00
    既然你都说了,以后出问题都是他们的锅。他们还是不做你就直接不用管即可,你把你分内的事情做好,早点把活做完摸鱼学习不香吗。
    cheng6563
        18
    cheng6563  
       2022-04-13 16:54:03 +08:00
    又不是不能用。
    后台的框架模板或者代码生成器就是这么返回的呗,所以说你不喜欢就单独开个接口。
    既然都用快速开发框架了,肯定以开发速度为重,这种低危漏洞也无所谓了。
    spicecch
        19
    spicecch  
       2022-04-13 17:02:36 +08:00
    你可以先开发,然后自己写好接口文档并定义字段,让后端来接
    iamqiwei
        20
    iamqiwei  
       2022-04-13 17:05:28 +08:00
    是不是用了若依的框架,这个框架本身就这样,我公司也是这样
    golangLover
        21
    golangLover  
       2022-04-13 17:07:01 +08:00 via Android   ❤️ 1
    垃圾后端呗,还有什么原因
    DinnyXu
        22
    DinnyXu  
       2022-04-13 17:10:57 +08:00   ❤️ 1
    后端返回这种有很多 null 值的字段是因为后端在查询的时候调用的是一个通用方法,这个通用方法对应的就是表结构的字段,也就是 domain 。如果你需要只返回一些有数据的字段,后端需要将 domain 转换为 VO ,或者是直接写 SQL 查询映射 VO 。这种返回很多 null 纯粹是涂方便,也不算是懒,只能算不规范.....
    mokevip
        23
    mokevip  
    OP
       2022-04-13 17:14:38 +08:00
    @xujinhui1 小公司,我算是前端的管理,还是不能完全摸鱼不管的。。
    mokevip
        24
    mokevip  
    OP
       2022-04-13 17:15:59 +08:00
    @iamqiwei 卧槽,一样!
    pelloz
        25
    pelloz  
       2022-04-13 17:16:26 +08:00
    这种情况一般出现在后端不知道前端需要什么字段,只知道前端需要这个业务内的字段。总的来说就是没人设计 api ,靠猜进行开发。
    mokevip
        26
    mokevip  
    OP
       2022-04-13 17:16:44 +08:00
    @spicecch 那后端炸了哈哈
    westoy
        27
    westoy  
       2022-04-13 17:27:18 +08:00
    不涉及安全(比如泄漏密码啊, 或者返回跨权限的字段)问题其实没什么毛病, 对 CDN 和后端缓存都挺友好的
    rabbbit
        28
    rabbbit  
       2022-04-13 17:28:28 +08:00
    别纠结这个,如果领导没说就别管,出事了也跟你没关系。
    对前端没影响,而且以后缺了啥字段也好取。
    到时候得罪了后端,布尔值全给你返回来 1 0 。
    R18
        29
    R18  
       2022-04-13 17:32:45 +08:00
    @yedanten
    想请教一下,数据库列名不也是语义化的吗。难不成返回前端的时候要另改一个名字。
    zzc032003
        30
    zzc032003  
       2022-04-13 17:45:26 +08:00
    @putaozhenhaochi
    为什么必须要转化啊? 如果仅仅是把字段名改名,意义何在哪?
    Bingchunmoli
        31
    Bingchunmoli  
       2022-04-13 17:47:45 +08:00 via Android
    第一如果接口不是面向业务开发而是面向数据开发,针对数据做返回是没问题的,如果针对业务就考虑前端处理和后端处理的优缺点,前端处理是大部分情况吧因为无所谓安全,只是展示,但是后端性能有点影响,前段在用户侧用前端可以节省一些后段性能
    Bingchunmoli
        32
    Bingchunmoli  
       2022-04-13 17:48:52 +08:00 via Android   ❤️ 1
    @iamqiwei ruoyi 是生成,如果你需要业务处理也可以写啊,面向数据的借口又不知道你业务需要忽略
    Bingchunmoli
        33
    Bingchunmoli  
       2022-04-13 17:49:22 +08:00 via Android
    @clf 但是有的接口需要呢
    Bingchunmoli
        34
    Bingchunmoli  
       2022-04-13 17:50:29 +08:00 via Android
    @xgfan 小公司这样很普遍,因为你做 vo 又不增加工资,卖出去就不管了,写代码时间多学习准备跳槽挺好的
    akira
        35
    akira  
       2022-04-13 17:52:23 +08:00
    你这是生怕别人不好脱裤么。。这下好了,直接 api 就能获取到数据了,渗透都不用了
    lecher
        36
    lecher  
       2022-04-13 17:55:25 +08:00
    缺一个 BFF 框架,展示数据不能受限于后端开发人员的约束。
    https://maguangguang.xyz/backend-for-frontend
    https://maguangguang.xyz/bff-governance

    看看之前 v 站用户的分享
    gogogo1203
        37
    gogogo1203  
       2022-04-13 17:57:40 +08:00
    golang 的解决方案是 应用层 和 数据层 的 user 写成两个 struct, 进出应用层用 user, 数据层出来要强制转化格式 。
    刚开始挺麻烦的, 做习惯了就好了

    ```
    package user
    type User struct {
    ID string `json:"id,omitempty"`
    Username string `json:"username"`
    Email string `json:"email"`
    Roles []string `json:"roles,omitempty"`
    PasswordHash []byte `json:"-"`
    }

    package db
    type User struct {
    ID string `db:"user_id"`
    Username string `db:"username"`
    Email string `db:"email"`
    Roles pq.StringArray `db:"roles"`
    PasswordHash []byte `db:"password_hash"`
    ....
    }

    ```
    TUNGH
        38
    TUNGH  
       2022-04-13 17:57:52 +08:00
    作为后端开发,给前端的每一个接口几乎都重写了 VO,你们后端这样写,不但懒,而且蠢.
    jhdxr
        39
    jhdxr  
       2022-04-13 18:00:31 +08:00
    如果本身接口就是简单的 CRUD ,为啥我觉得除了潜在的安全风险(敏感字段,例如密码之类的。但这也只要配置一个黑名单)以外这么做没啥问题?除了浪费了一点流量。上面还有人提字段名泄露啥的,改个名掩耳盗铃吗?又是真有一个注入点,想要拖数据的还需要在乎你有没有泄露字段?现在都是自动化工具了。
    446ENzu91KZ73A33
        40
    446ENzu91KZ73A33  
       2022-04-13 18:00:59 +08:00
    @akira api 本来不就是获取数据的吗?这个应该要怎么改?
    darkengine
        41
    darkengine  
       2022-04-13 18:02:47 +08:00
    @rabbbit 0 和 1 还算好的,以前接过一个屎山,后端返回来的布尔值是 1 和 2 。。。。。。。
    jorneyr
        42
    jorneyr  
       2022-04-13 18:03:37 +08:00
    @yedanten 你这是想给数据库字段加密么。
    Qseven
        43
    Qseven  
       2022-04-13 18:04:23 +08:00
    对这种一个实体从底贯穿到外的做法,十分鄙视,写什么代码,麻烦回去种田。
    seakingii
        44
    seakingii  
       2022-04-13 18:05:50 +08:00
    建 VO 是好习惯

    不过为了能早点下班的话懒点也能理解...
    yyf1234
        45
    yyf1234  
       2022-04-13 18:23:05 +08:00 via iPhone   ❤️ 2
    艸,以为看到我公司的代码了
    labulaka521
        46
    labulaka521  
       2022-04-13 18:43:00 +08:00
    labulaka521
        47
    labulaka521  
       2022-04-13 18:43:50 +08:00
    @darkengine 哈哈 我们用的 grpc + golang 布尔值在 proto 里就是定义成 1 或 2
    Dragonphy
        48
    Dragonphy  
       2022-04-13 19:04:36 +08:00
    我竟然觉得没什么问题[假笑],不想要无关字段可以针对不同的需求建立 VO ,而且前端取模也没啥大不了的吧,我们的后端我让直接写 SQL[二哈]
    sampeng
        49
    sampeng  
       2022-04-13 19:23:57 +08:00   ❤️ 1
    这种后端写什么程序,回家种田吧。

    先不说偷懒不偷懒,不摸鱼的员工不是好员工。

    单说反正机器流量钱不是他出,按 LZ 的这个例子,最少流量费用要多出 50%出来。服务端 GZIP 需要 cpu 。cpu 利用率多出 50%。客户端需要解压缩,需要 get body ,客户端也是要损失一部分损耗在里面。

    你们后端 leader 是吃屎的?这都不管?那管啥?
    rabbbit
        50
    rabbbit  
       2022-04-13 19:38:48 +08:00
    @sampeng
    息怒,这都不算啥,你还没见过批量删除让前端自己写循环发请求挨个删的。
    dengshen
        51
    dengshen  
       2022-04-13 20:09:11 +08:00 via iPhone
    @TUNGH 做 node 不仅要重写 vo 还要重写 dto 日了狗了
    ccppgo
        52
    ccppgo  
       2022-04-13 20:24:18 +08:00
    既然是 java 。。属性为 null 这种东西用 jackson 处理一下不就好了么
    asfas1246
        53
    asfas1246  
       2022-04-13 20:57:17 +08:00
    我一个接口,返回了 45 万个字符。其中需要的,10%都不到。
    aliveyang
        54
    aliveyang  
       2022-04-13 21:02:48 +08:00
    什么阶段干什么事,不怎么重要的项目套模板没什么不好的
    Cielsky
        55
    Cielsky  
       2022-04-13 21:03:57 +08:00
    @mokevip 那你跟后端管理说不就完事了,然后保留聊天记录方便甩锅即可
    XCFOX
        56
    XCFOX  
       2022-04-13 21:15:28 +08:00
    这时候就体现出 GraphQL 的好处了,后端还是直接抛从数据库里取出来的对象,前端需要什么按需取就行了
    PopRain
        57
    PopRain  
       2022-04-13 21:54:12 +08:00
    楼上说的一个对象用到底就鄙视不能认同, 大部分企业应用有复杂的逻辑和界面,每个界面(前端)对应一个 VO , 那管理起来太复杂了。。。。
    unnamedhao
        58
    unnamedhao  
       2022-04-13 22:17:16 +08:00
    前后端接口规则咋定,一般看谁能打过谁
    morize
        59
    morize  
       2022-04-13 22:30:47 +08:00
    作为前端,我觉得返回 null 没什么问题,做数据防御是基本的好吧。可选链 ?. 又不麻烦。
    多余的字段怎么说呢,难道来需求了前端后端一起改吗,太麻烦了吧。
    觉得不好自己再 format 一次咯,要是你习惯把接口的数据直接抛到 view 层当我没说。
    lanlanye
        60
    lanlanye  
       2022-04-13 22:36:56 +08:00
    暴露了表结构可能是一个问题,另外如果冗余数据的内容非常多导致传输受到影响也不好。
    除此之外其实没什么太大的问题,而且我个人的看法是少量的计算和格式转换交给前端做更好,毕竟前端的计算压力分散在每一个客户端(浏览器)上,而后端处理则是一台服务器处理所有请求需要的数据,显然前端处理可以分散压力。

    当然实际项目中大部分人这么做是因为懒(摊手
    aababc
        61
    aababc  
       2022-04-13 22:44:43 +08:00
    @labulaka521 卧槽,这么高级的吗?感觉这样会被人打死的!
    KHfqLAYYS6BKJT3R
        62
    KHfqLAYYS6BKJT3R  
       2022-04-13 22:50:26 +08:00   ❤️ 2
    楼上那么多说暴漏表结构的,专门起个跟数据库里表字段不一致的 VO ?
    lower
        63
    lower  
       2022-04-13 23:07:18 +08:00   ❤️ 3
    你实在看不起跟你协作的后端同事的话,就找他的 leader 或者老板来协调,在论坛来吐槽大可不必;
    聊天记录里对方也说了,你不方便处理他再给你写个接口……有什么毛病么?

    大家都是吃这碗饭的,想挑毛病怎么都能挑几条;
    前后端分离的模式本身就会引入一些新的问题,不可能有完美的方案能解决所有可能的隐患;

    工作中我最害怕的就是遇上那种事儿特别多,总是坚持自己想法的同事或者领导,口一张就要让别人怎么怎么配合他工作,理由也是一大堆,每次都非要争赢,完全不管别人的情况……
    😔
    labulaka521
        64
    labulaka521  
       2022-04-13 23:52:09 +08:00 via iPhone
    @aababc 因为 golang 里的默认值问题只能这么搞了 目前还没被打 因为不是我设计的😆
    marcojbk
        65
    marcojbk  
       2022-04-14 07:46:20 +08:00 via iPhone   ❤️ 1
    那我说个相反的,我司前端从来不处理任何数据,全都靠后端我给他处理好,他只负责展示。
    FawkesV
        66
    FawkesV  
       2022-04-14 08:43:10 +08:00
    就是偷懒而已. 正常来写要写 vo 类映射的.
    changdy
        67
    changdy  
       2022-04-14 08:44:09 +08:00
    哈哈哈 ..前后端 势如水火
    你说后端菜 ,后端说你娱乐圈 ..
    你说后端 null 全字段 ,后端说你 不会用 GraphQL ...

    老老实实搬砖吧... 不要把公司的压迫 转移成了 前后端的撕逼 ....
    masterclock
        68
    masterclock  
       2022-04-14 09:06:37 +08:00   ❤️ 1
    null 是 null ,不存在是不存在,是什么就返回什么

    取模 10 这种操作让后端做??你要取模 10 ,另一个前端要取模 11 ,怎么处理?
    zarvin
        69
    zarvin  
       2022-04-14 09:07:47 +08:00
    无解,后端不做,肯定就是前端做,工作量转移而已
    Felldeadbird
        70
    Felldeadbird  
       2022-04-14 09:20:41 +08:00   ❤️ 1
    后端来说一下,这种低风险的字段映射一般情况可以忽略安全考量。全字段输出更加省事。后端不知道前端要什么数据啊。没有明确规范下,非敏感库全字段输出节省了前端沟通成本。

    就算你做了字段处理,人总会犯错的。如果觉得敏感应该找后端和负责人来处理。
    wolfie
        71
    wolfie  
       2022-04-14 09:35:22 +08:00
    OP 就是平时接触到的高血压前端
    itechnology
        72
    itechnology  
       2022-04-14 09:52:22 +08:00   ❤️ 1
    作为一个后端,我觉得他们这样做完全没问题,无非就是有点不规范而已。
    wonderfulcxm
        73
    wonderfulcxm  
       2022-04-14 09:58:58 +08:00 via iPhone
    laravel Eloquent ORM 可以很方便设置隐藏、显示哪些字段。
    Vitta
        74
    Vitta  
       2022-04-14 10:07:54 +08:00   ❤️ 1
    《用你写的接口我都不如直接用云数据库》
    knightdf
        75
    knightdf  
       2022-04-14 10:11:05 +08:00
    返回给前端的到底是 VO 还是 DTO ?怎么看楼上两种叫法都有?
    v2orz
        76
    v2orz  
       2022-04-14 10:12:01 +08:00
    不好说对错,这种事,关系好的商量一下就好,早点搞完早点跟前端兄弟吃火锅去
    不是所有系统都要考虑什么多传几个字符、gzip 压缩这些的,具体场景具体分析
    人家就要快,就要便宜,给你 DeadLine ,只能提前不能推迟

    不过我也遇到过,字段为 1 ,显示成第 1 行,都要后端给他转换好的人
    RealJacob
        77
    RealJacob  
       2022-04-14 10:20:23 +08:00
    有时候多带一些数据是正常的,但是该处理的数据还是要处理好就可以了。别就查个表什么都不处理
    p1gd0g
        78
    p1gd0g  
       2022-04-14 10:21:08 +08:00
    我做全栈的时间就爱这么干,省事,还能给服务器减压
    keepeye
        79
    keepeye  
       2022-04-14 10:21:52 +08:00
    哈哈 搞前端的火气这么大吗?来哥请你去大保健消消火,298 套餐怎么样
    l00t
        80
    l00t  
       2022-04-14 10:31:42 +08:00
    无非是懒了点,又不是不能用…… 你要说这是不是一个好的设计,那肯定不是。但也不算什么大事,写程序还是要提高自己的适应性,你总会遇到各种烂代码烂接口烂项目的。
    yor1g
        81
    yor1g  
       2022-04-14 10:32:38 +08:00
    有没有接口文档 , 有就他不对, 没有的话没啥问题. 后端都想直接给你一个方法, 自己写 sql 好了, 想要啥字段自己查
    l00t
        82
    l00t  
       2022-04-14 10:36:09 +08:00   ❤️ 1
    @sampeng 你要考虑这么极端那解释性语言可以都直接下岗了。HTTP 本身效率也不高,可以废了。
    zealinux
        83
    zealinux  
       2022-04-14 10:45:28 +08:00   ❤️ 1
    建议用 GraphQL
    lscexpress
        84
    lscexpress  
       2022-04-14 10:49:05 +08:00
    @asfas1246 啥接口啊?吹牛有点过了吧
    sampeng
        85
    sampeng  
       2022-04-14 11:15:01 +08:00
    @l00t 编程语言是合理的浪费,并不极端。。lz 这种情况是不合理的。。不能偷换概念
    daimubai
        86
    daimubai  
       2022-04-14 11:23:37 +08:00
    他喜欢你
    HeHeDaGe
        87
    HeHeDaGe  
       2022-04-14 11:26:21 +08:00
    yml 配置行就行了

    jackson:
    default-property-inclusion: non_null
    akira
        88
    akira  
       2022-04-14 11:33:20 +08:00
    @mu666 不一样的,应该尽量只返回客户端需要展示的数据,遵循最小化原则。 同时数据里面的各种 id 应该尽量不可枚举, 特别是规律性的自增 id 等,均不应该返回给前端,不然非常容易出现平权漏洞。另外各种敏感数据以及隐私数据就更加要小心了,国内的话还好,没啥人较真,国外爆一个漏洞,公司直接可以关门了。

    最后,这个后端看起来似乎是直接 select * ,然后就全部返回了,这种技术债迟早要还的。
    keeguai
        89
    keeguai  
       2022-04-14 11:38:09 +08:00
    交给前端做也能说得通,毕竟后端更多考虑通用性,给你这个功能取模 10 了,其他功能调用要不要去掉?
    另外这种计算处理最好还是交给前端,前端计算压力是客户浏览器的,放在后端,就是公司服务器承担了。
    至于返回 null 值,后端可以过滤,甚至可以自动过滤,JSON 转一下就没了,但是有时候 null 值也是有意义的。
    你这个问题是你们公司前后端协同问题,是接口协议谁来定?是前后端谁来决定业务逻辑的问题。
    跟技术没关系,是个管理问题。
    libook
        90
    libook  
       2022-04-14 12:15:20 +08:00
    都是管理上的问题,前后端应该在工作内容方面有个清晰的界限。
    potatowish
        91
    potatowish  
       2022-04-14 12:26:54 +08:00 via iPhone
    个人项目倾向于只返回需要的字段。公司项目那就另说了,只要管理没严格要求,那就怎么方便怎么来,毕竟工期在那摆着呢。你在和后端为了这些字段该不该一起返回争的面红耳赤的时候,隔壁组的兄弟已经下班了~
    falcon05
        92
    falcon05  
       2022-04-14 13:04:02 +08:00
    那肯定不对的啊,请求某个用户信息接口,把密码也暴露出来怎么行。
    ZSeptember
        93
    ZSeptember  
       2022-04-14 13:14:26 +08:00
    看风格,RESTful 风格的 API 关注的是业务模型,返回的都是模型所有字段,而不是根据前端需要返回字段。
    当然,你们现在的风格就是 RPC 风格,后端应该只返回前端需要的字段就可以了
    vyronlee
        94
    vyronlee  
       2022-04-14 13:17:20 +08:00 via iPhone
    经典语句来了,”又不是不能用”。API 设计者不从使用方考虑便利性,而从自身实现来决定 API 长啥样,这种 API 就是不及格的。
    Bingchunmoli
        95
    Bingchunmoli  
       2022-04-14 13:54:55 +08:00
    @akira 我们主键 ID 是过滤的其他以为都是业务需要,所以也会返回,无非是这个接口与另一个接口的问题。
    Bingchunmoli
        96
    Bingchunmoli  
       2022-04-14 13:58:19 +08:00
    前端计算之前也有人讨论过, 因为比如 app 要展示分,PC 展示元,那么后端是两个数据还是说我一个数据,前端处理好。 显而易见面向数据通用性更广,但是面向业务(通常都是面向业务开发),两个字段更方便,前端不需要做适配
    liuidetmks
        97
    liuidetmks  
       2022-04-14 14:02:19 +08:00
    直接找老板谈,
    "你这有这样的员工,我活没法干了, 我还是他,选一个吧"
    masterclock
        98
    masterclock  
       2022-04-14 14:11:28 +08:00
    第一天:App 显示 分,后端返回 100
    第二天:App 显示 元,后端返回 1

    于是未更新的 App 上全部都显示 1 分
    jhdxr
        99
    jhdxr  
       2022-04-14 14:12:08 +08:00   ❤️ 2
    @akira 理论上是这样,但是实操是另外一回事。你数据库表设计范式全遵守了?

    平权漏洞和是否返回给前端没有关系,而是应该做好权限校验。指望通过不告诉别人来解决漏洞,就好比“自研”各种加密算法,指望通过算法的保密来保证安全性。

    别总觉得国外的月亮圆,信用卡数据这么多公司泄露了,哪个关门了?

    另外举一个具体的例子,获取用户信息。一个常见的,也是许多人口中偷懒的例子是直接一个 select * (当然,过滤掉诸如密码之类的敏感字段)作为一个 API ,前端自己去选取需要的信息。另外一个是根据每一个业务场景分别去做一个 API 。当然,还有 graphql 这种解决方案。我并不认为第一种方案一定是不好的。
    wolfie
        100
    wolfie  
       2022-04-14 14:14:29 +08:00
    这种后端建议直接开除,多反了几个 null 搞得前端直接宕机不会写代码了。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1790 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 16:31 · PVG 00:31 · LAX 09:31 · JFK 12:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.