永远不要在代码中使用“User”这个单词

查看:306
本文介绍了永远不要在代码中使用“User”这个单词的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

来自:众成翻译

译者:有马

链接:https://www.zcfy.cc/article/never-use-the-word-user-in-your-code


当你意识到你在项目开始时做的轻量、简单的设想竟然完全错了时,你已经投入了六个月的时间在这个项目上。现在你需要解决这些问题,才能让这个系统继续运行下去,你发现你用在这个项目上的精力远远超出了你的预期,如果一开始就用正确的方式来做,就不会发生这样的事。

今天,我要告诉你的是一个经常犯的错误,一个会给你带来无穷无尽的问题的单词,那就是User

这个单词有两个最基本的错误:

  1. 对你的需求来说 User几乎从来都不是一个好的描述。

  2. User 会导致一个基本的设计安全缺陷。

User 的概念是模糊不清的,使用更精准的术语几乎总是能起到更好的效果。

你没有使用者

最开始,没有任何一个软件系统真的有使用者存在。乍一看User是一个好的描述,但是你稍微一想就会意识到你的业务逻辑实际上比这要复杂的多。

我会使用三个例子,从一个极端的情况出发。

机票预订系统没有User

我曾经给机票预订系统写过访问控制逻辑,下面只是一小部分需求:

  • 旅客可以使用预定记录码通过网站查看预定信息。

  • 购买者可以通过信用卡号后四位数在网站上修改预订信息。

  • 旅行社可以查看和修改他们的预订。

  • 航空公司的值机人员可以根据角色和航空公司来查看和修改预订信息,这需要旅客提供身份信息。

不再一一列举。一些与人类相关的基本概念是旅客,代理(网站也可是看作代理)和购买者。User这个概念根本没用,并且在许多请求中我根本不会使用这个单词,举个例子,我们的请求必须包括旅客和代理人的证件,而不是使用者的证件。

Unix 没有 User

我们看一个不太一样的例子。Unix (这些天被称为POSIX)有用户,他们可以登录并执行代码。这样看起来很不错吧?我们深入看一下。

如果我们把所有都当作User的话,我们将会有:

  • 使用终端或者图形界面登录的人

  • 像邮件或者web服务器这种系统服务也会以User的身份运行,例如nginx可以以httpd用户运行。

  • 在服务器上经常会有多人共享一个管理员账号用来SSH登录(例如,亚马逊的Ubuntu虚拟机默认SSH账号就是‘ubuntu’)

  • root 身份,和上面其他身份都不同。

上面四个是几乎不同的概念,但是在POSIX上他们都是 User。 一会儿我们就会看到,把这些概念都称为User会导致很多安全问题。

在操作上,因为POSIX的用户模型边界存在,我们甚至不能找到一种方式说只能让 Alice 和 Bob 通过这个账号登录。

SaaS 服务提供商没有 User

Jeremy Green 最近就用户模型在SaaS中的应用在推特上发文,它第一次提醒了我写下这篇文章,他的基本观点是SaaS 服务几乎总是:

  1. 某个组织中的一个人支付服务费用。

  2. 一个或多个人共同使用这个服务。

如果你一开始就把这些人作为一个用户,你将会陷入一个痛苦的世界。你无法建立团队模型,你无法组建同时为多人支付的模型,然后你就会开始改造你的系统。现在你在SaaS案例中学到了一课,我们来看一看你的生活。

但是这只是众多例子中的一个:User的概念太模糊了。如果你开始怀疑User这个词,最终你可能发现你其实只需要两个概念:团队(用来组织关系和支付)和成员(实际使用服务的人)。

User 是一个安全问题

"User" 这个单词不仅是业务逻辑的问题,它也导致了一系列安全问题。User 这个单词如此的模糊以至于从根本上将两个概念合并了:

  • 一个人。

  • 他们在软件中的代表性。

为了说明这个问题,假设你正在访问一个居心不良的网站,在它服务器上的图片导致了你的浏览器内存溢出。远程网站控制着你的浏览器,并且开始将你的文件上传到他的服务上。为什么它能这样做?

因为浏览器是以系统用户的身份运行的,它被认为与人类身份的你相同,实际上你们是不同的。

这篇关于永远不要在代码中使用“User”这个单词的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆