V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
xxbutoo
V2EX  ›  MySQL

在整个应用中, v 友是怎样去禁用某个用户的

  •  
  •   xxbutoo · 2021-02-16 14:29:08 +08:00 · 3151 次点击
    这是一个创建于 1137 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一直好奇这么个逻辑
    v 友们是怎么去 禁用某个用户的?
    直接在表里面加个 status 标记吗

    但是这样感觉需要整个团队去了解这个字段,不然有个新来的查询的时候忘记写 status 条件了 就会出现尴尬的情况

    我觉得肯定有更好的方案 只是我没想到。
    17 条回复    2021-02-20 00:48:53 +08:00
    felixcode
        1
    felixcode  
       2021-02-16 14:42:54 +08:00 via Android
    有个 blocked 字段不就行了,True False
    also24
        2
    also24  
       2021-02-16 14:44:28 +08:00   ❤️ 8
    禁用状态本来就是业务相关的,特别是此用户产生的内容能被其他用户查看的时候。

    比如说,一个用户被禁用后:
    用户自己是能登陆但不能操作,还是直接禁止登录,还是等同于删号不存在?
    用户的个人信息页是一切如常,还是加封禁标记,还是屏蔽内容,或者等同于删号不存在?
    用户已经发出的评论、内容等,是一切如常还是进入锁定状态,或者直接删除相应内容?
    用户已经的评论被嵌套评论,内容被评论或点赞的记录,是否还有效,操作人那里是否还能看到记录?
    用户已产生的订单是否还可以操作,如果有未完成的订单是否要自动取消?
    用户的私信对象是否还能查看历史记录,是否还能回复私信?
    用户是否存在剩余的虚拟资产,是否提供处置方式?

    我觉得这个『禁用』,还是需要产品需求方先明确定义了,才能更好的设计如何实现。
    而一旦将相应的业务需求明确定义了,应该也不会存在 status 忘查询的情况(除非需求方先忘了)。
    imn1
        3
    imn1  
       2021-02-16 15:00:48 +08:00
    鉴权是必须执行步骤,如果忘了写,就是工作失误了,除非他写的部分无须鉴权

    不用考虑谁有没有写的问题,而是考虑有没有手册说清楚,以及有没有相关的工作要求
    然后用什么,怎么用,要看业务逻辑
    xuanbg
        4
    xuanbg  
       2021-02-16 15:08:43 +08:00
    用户身份认证 /鉴权有统一的入口,不存在别人不了解造成失误的情况。
    heyjei
        5
    heyjei  
       2021-02-16 15:13:13 +08:00
    接口封装好后给别人调用啊。
    340244120w
        6
    340244120w  
       2021-02-16 15:26:58 +08:00 via iPhone
    状态,创建日期,修改日期是除了 id,用户名,密码之外行业默认的必备字段了。

    所以,有的人不知道这种常识,要改变的是他而不是系统🦆
    YouLMAO
        7
    YouLMAO  
       2021-02-16 16:06:38 +08:00 via Android
    V
    站被封是随机重置密码


    所以



    只要用 Gmail 再来重置密码,立刻复活







    不要作恶,小心出门被车撞死
    xxbutoo
        8
    xxbutoo  
    OP
       2021-02-16 18:39:45 +08:00
    @xuanbg 比如用户 id 2 的 status = 1 的表示禁用

    然而有个业务类似这样 $user->where('id', 2) ->find() 吧数据查出来了
    CEBBCAT
        9
    CEBBCAT  
       2021-02-16 20:18:31 +08:00 via Android
    @YouLMAO 兄弟你想想这个叫“被封”吗?
    YouLMAO
        10
    YouLMAO  
       2021-02-16 20:22:43 +08:00 via Android
    @CEBBCAT IP 会被封的,需要换个机场,重置密码
    xuanbg
        11
    xuanbg  
       2021-02-16 22:38:20 +08:00
    @xxbutoo 提供用户查询接口啊,怎么能应用自己查数据库呢?都 2021 年了,该把微服务搞起来了呀。不行就直接用我的吧……自己去我的 github 找,我就不广告了。
    badcode
        12
    badcode  
       2021-02-16 22:50:38 +08:00
    规则一旦写死
    有些人就按照这个来各种破坏
    还给了他 BB 的理由

    ---------------------以上来自 v2


    个人认为,不太可能让这个规则明示,
    换一句话就是,这个规则在管理层内部或者站长会根据当前的情况而定。
    also24
        13
    also24  
       2021-02-16 22:54:09 +08:00
    @xxbutoo #8
    所以说还是要看业务需求啊……

    就算一个码农注意到了 status 字段,那对这个字段的用户该怎么处理,还是不知道啊。
    如果需求方没有明确说明,这个业务对被封用户要怎么处理,那码农怎样越殂代疱来决定呢?
    aristolochic
        14
    aristolochic  
       2021-02-16 23:40:56 +08:00
    上面说到了微服务
    其实单体应用也要拆分模块提供接口的
    不明白为什么认为只有微服务才能解耦
    任何系统大起来之后里面也不能是糊糊叭
    微服务一开始就注意这些,可单体应用老油条们也各有各的解决方案
    Java 的 Spring 那些不有业务层吗,不是用来干这个的?
    Rails 充血模型,一开始写在模型里,后来复杂起来写在 Concern 里,再复杂一点学 Java 用 Service Object,等成熟了抽离出 Engine,就成了一个完整的独立模块
    Django 的 App 应该也可以做这些(但我不太熟不好说明)

    这又不仅仅是 Ban 一个用户如何实现的问题
    其他涉及数据敏感的地方,也要谨慎啊

    就算内部是一团浆糊,维护者需要直接访问数据,
    但还有手册吧?虽然确实可能“忘记写什么东西了”,
    要是 CodeReview 没有铺开也可能发现不了
    但这个不是还有测试管着呢嘛
    怕什么怕
    chouchen
        15
    chouchen  
       2021-02-17 11:56:38 +08:00 via iPhone
    这种最简单的字段都能漏的人,他写的代码你敢用吗?
    dorothyREN
        16
    dorothyREN  
       2021-02-17 15:07:01 +08:00
    密码前面加个!
    xxbutoo
        17
    xxbutoo  
    OP
       2021-02-20 00:48:53 +08:00
    @felixcode 不是啊同学,blocked 字段和 status 字段有什么区别
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5402 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 08:55 · PVG 16:55 · LAX 01:55 · JFK 04:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.