复杂度其实是降维

突发奇想(可能也没啥新奇的,也许就是无知而已)

其实代码中控制复杂度的过程就是降维,或者说把一个复杂的结构用多项式来标识,每个项就是一个类(对象),然后把他们加起来。

如果做不到这一点,那么代码的复杂度将不可控,整个系统也就越来越不可控,最终烂掉。

貌似,代码也有它的生命周期,很少有代码能够“活到”足够长的时间,而变得不可控。

想象,一个函数,里面是一大堆的ifelse语句,每个if就是一个分支,每个分支就是一个乘法,每多一个乘法就是一个新的维度。所以我们常常将函数拆分成若干个对象的组合(通常是加法)。

不能忽视懒B的勤奋程度

在微信提供的PHPSDK开发代码里发现有一段代码,为了转换字符串,而把对象放到数组里再拿出来。

怎么能想出来的~ 用常规的方法不好吗?

能琢磨出这种办法的人,微信应该fire掉吧。话说回来,看来是完全没有code review啊。

有感。

给数据穿上裤子

最近华住又被拖库了,5亿的个人数据就这么泄漏了。感觉好卑微,原来每个人不过是一条数据。

怎么解决这个问题呢?

被“拖库”泄漏数据的原因是:敏感信息在数据库中明文存储。那么很自然的想法是:给数据“穿上裤子”,也就是进行加密。

比如:

电话号码:18633334444 变成 186aaaabbbb ,这里示范的是最简单的字符替换,这种算法也叫凯撒密码。

通过在加密中添加salt来避免太容易的解码,但貌似无济于事。

普通的凯撒加密可以容易地推算出来,即便是更加复杂的加密方式,人家已经获取到数据了,大不了费点事而已,毕竟是对称加密的。

话说回来,如果代码都已经被拖走了,貌似也没什么救了。

但是,对敏感数据进行部分加密还是有意义的,比如,不会容易被“撞库”。

另外,对于数据的提取,毕竟有时候会需要用户的联系方式进行短信营销,以前的做法(也说明了我们对用户的隐私是多么无视)是:直接从数据库里把数据导出来,然后交给短信发送供应商或者程序员通过短信发送接口进行批量发送。这么人的操作很难避免数据不外露,尤其是不靠谱的短信供应商。

所以,从运营的角度来说,也要通过流程来避免人为的数据泄漏。可以通过开发专用的“数据提取”功能来根据权限来获取敏感数据,同时记录下获取历史记录。就算追查追究法律责任时也是有据可查,光是这个“可追溯”也可以很大情况下避免人为泄漏。

顺道发现了一个很不错的关于数据加密的网站:https://www.dcode.fr/

代码中常见的命名问题

发现在代码命名中有一些常见的错误。我发现大多数是中国人犯这种错误,老外也有。

1. 设计模式后缀

比如 XXXFactory, XXXFacade, XXXObserver 等等,其实完全没有必要增加这种后缀。

2. 拼音命名法

这个我完全是带着个人偏见,相比英文,中文的表达能力更强,也就导致,名字的“意境”更多,更容易误解。倒不是因为使用拼音。

3. 词性错误

类大多数是名词,但如果是command模式,那类名可能会是动词,取决于类的本质行为。方法/函数通常是动词或者动宾短语。

4. 冗余

没有充分使用语言特性,如namespace、package等。比如 AlipayTradeService, AlipayWapTradeService…这种。好不环保哦。

基本上每当出现“重复”时,意味着代码需要重构或者精简了。

5. 直译法

比如,微信的“统一下单”,代码中是 ” unified ” – 统一, “order” – 下单。让我来推测一下这种名字的由来:

最开始,在线上支付和pos系统里有“收单”一说,英文用“acquire”,后来可能pos和线上合并了,也就是“统一”。其实似乎没有增加“统一”的必要。

本质上其实还是收单。

蛋疼的utf8-bom

测试了一下微信小程序的登录,发现wx.request的返回无法正常地被转换为json对象。

手动加入后一直报错:

仔细一看,返回的json内容最前面有4个“小红点”,鼠标移上去显示是:\ufeff。

google了一下,是utf-8的bom,解决办法是将文件转换一下,去掉bom。

按照这篇文章的方法,发现这三个文件中包含是utf-8 bom编码:

pkcs7Encoder.php

errorCode.php

wxBizDataCrypt.php

也就是微信官方提供的数据加密、解密处理类。

让我比较费解的是,我只是在类中调用了上述三个文件中的类,并且调用也是正常,但是将结果json_encode到前端时就会包含bom。猜想造成这个的原因是那位写代码的工程师是用的windows,然后不小心插入了bom,而且自己是不会发现的。然后所有使用的它的人都悲剧了,因为php不认这几个字符。参考

因为这个问题,耗费了几乎一下午的时间,极其蛋疼。

更蛋疼的是,如果将来上面的三个类有更新(但是没更新utf-8 bom),那么今天遇到的问题还会再出现,这种问题还真是第一次遇到。

PS. 如果是用phpstorm的话,可以直接右键点击文件,然后「Remove BOM」。

PS. 观察到返回结果中“小红点”的个数,就是包含BOM的文件个数。

PS. 一不小心又掉了一坑,这次的现象是微信内浏览时页面的头部莫名出现几个“&#65279”的空字符,还是因为微信的那几个文件,有一个文件在删除bom时候漏掉了。

关于权限访问控制设计

所谓“权限”,可以抽象地理解为:
主体(subject)对客体(object)的部分或者全部属性(attribute)进行的的操作(operation)
“访问控制”中的“操作”可以简化为读(read)和写(write)。
比如,
张三 修改 商品的库存
这里,
主体:张三
客体:商品
属性:库存
操作:修改(write)
通常这里的“客体”的“属性”“操作”也被成为“资源”。
插一句,我们通常所说的角色、角色组什么的,属于对这里“主体”的组织。
*  粒度
这里会涉及到一个粒度问题,也就是,访问控制要控制到多细,一般比较简单的系统中,我们会控制到“客体”这个粒度(也就是直接将属性全部包含到客体里)。
比如,张三修改商品
即,张三可以修改所有商品的所有属性。
但有时候我们会需要将粒度控制到部分属性,
比如,
库管人员(角色)可以修改商品的库存(一个属性)
张三可以修改商品的基本属性(多个属性)
*  过滤
还有一种情况,可能需要主体只能访问一部分客体。
此时,需要根据客体的某些属性进行过滤。
比如,
张三可以修改某个供应商(过滤属性)的商品库存
在描述时,可能是这样的:product{vendor:A}
这里的过滤表达式可能会比较复杂 – 比如还会增加类似条件:价格不高于100元。
类似的,主体和属性都存在需要过滤的情况,属性的过滤也就产生上面提到的“粒度”问题。
*  分配
权限本身也是一种“客体”,权限分配这个动作本身也是一个访问控制资源。
比如,
管理员可以分配商品的修改、读取权限给用户或角色
或者,重新按照上面的逻辑表达:
管理员(主体) 修改 商品的操作权限(客体) 主体(属性)
*  总结
访问控制逻辑的伪代码为:
function access(subject, object, attribute operation)
    permissions = 所有对object的权限定义
    permissions = filterBy({id:1}, stock, write)
    foreach(permissions as permission)
        if(permission.subject filter({role:admin})) return true
    return false
access({role:admin}, {id:1},{stock},{write})

关于用户积分体系

自工作以来有意无意地也做了几个大大小小的和积分相关的项目/产品。做个简单的总结。
先说本质,积分的本质是用来通过一个类似货币的东西来刺激用户活跃,或者说激活(activate)用户。比如虽然现在微信支付正在侵蚀支付宝的领地,但是由于微信支付没有相应的用户体系,所以在这一块算是遇到了短板,下一步再想“侵占”支付宝就很难了。
从定义的角度来说,我觉得英文里的两种说法可以方便区分积分的两个“变种”:
points – 积分点,比如bonus point、loyalty point,最接近货币的概念,所以一般情况下,这个积分点是可以进入账户支付体系的。用户获取成本一般较低,因为对用户的身份和信用度和消费力不是特别关注。
credit – 信用点,更强调用户在系统中的信用度,这个credit可能会和某些特权关联,但通常这种积分不会进入账户支付体系,而是通过独立的兑换中心来完成。用户的获取成本相对比较高,比如必须有下单才能获得。
目前,大多数的积分可能更偏向于后一种,因为直接和支付体系关联会产生财务核算、成本、对账等等一系列操作。但不可否认从用户角度来说“积分当钱花”还是很诱人的一件事。
还有一个问题是,如果积分和货币直接挂钩,相当于创造了一个经济体系,有积分消费、积分产生、通货膨胀、供需决定价格等一系列更大的坑。很多时候,我们会直接锚定一个积分价值,比如对应到1分钱 = 1积分。但如果积分不能很好流通和消费的话,用户可能会更加反感。
我个人偏向credit,并且将积分简化为只能在“兑换中心”或者“礼品中心”使用,同时不锚定积分价值,运营人员可以根据实际情况灵活掌握兑换“汇率”,通过限制兑换数量、周期而获得更多的运营空间。相对主动一些,而不是像前者那样需要不停地监控经济体系的健康状况,每天看着发那么多钱而提心吊胆。如果实在想要实现积分抵现金,可以通过让用户兑换代金券然后来“曲线救国”,当然效果肯定不如“积分抵现”直接,但只要用户对你的抵用券有兴趣或者抵用券确实有价值,而且这种做法的最大好处还是“相对可控的” — 用户兑换多少券、使用多少券都可以进行运营上的限制。
 
再说说数据指标,既然是针对activation,就主要看:积分的获取情况、使用情况,以及积分使用用户的订单转化情况、付费用户比例。
 
但是无论是哪种方式,积分都是一个运营占主导的工具,在体系框架完成后,需要不断进行运营上的优化。

关于用户账户、授权和密码管理的12个最佳实践

翻译:zhangv
在处理用户账户、授权和密码管理时,有时情况会非常复杂。对很多开发者来说,账户管理时一个经常被忽视的问题。对产品经理和用户来说,结果常常是始料未及的。
幸运的是,Google云平台(GCP)包括了一些工具来帮助你安全地创建、处理用户账户。无论你负责的是架设在Google Kubernetes Engine上的网站,基于Apigee的API服务,使用Firebase的app,还是其他需要验证用户的服务,本文将展示给你一个安全、可扩展、可用的账户验证系统的一些最佳实践。
1 . 密码不要明文存储
我认为账户管理最重要的一条法则是:安全地存储敏感用户信息,包括密码。对待这些数据一定要慎重而合理。
在任何情况下都不要以明文来存储密码。你的服务应该存储足够强的密码不可逆加密摘要 — 使用类似PBKDF2,Argon2,Scrypt或Bcrypt来创建。摘要时还需要加入随机字符串(盐)。不要使用已经废弃的摘要算法,如MD5,SHA1,并且在任何情况下都不要使用可逆加密算法或者自己发明摘要算法。
在设计系统之初就要考虑到系统被黑的情况。问自己“如果今天数据库泄漏,用户是否会收到影响?我们可以做哪些补救措施?”
另一个问题:如果在用户提供给你密码后,你可以获得铭文的密码,那么你的实现方案就是有问题的。
2 .支持第三方的身份授权
第三方身份授权可以让你依赖外部的可靠服务来验证用户身份。Google, Facebook和Twitter是最常用的身份授权提供方。
你可以使用诸如 Firebase Auth的服务来帮助你整合外部身份认证授权。优点是:包括简单的管理界面,更不容易被攻击,多平台SDK。我们在下面会介绍更多特性。
3 . 分清楚用户身份和用户账户的区别
你的用户不是邮件地址,也不是电话号码,更不是OAuth服务返回的唯一标识。你的用户是他们在你的应用服务中的一系列个人数据和体验的累积。优秀的用户管理系统体现在用户个人数据各个部分设计上的低耦合和高内聚上。
用户账户和隐私信息的分离可以让你简化实现第三方身份授权的难度,并且可以允许用户修改用户名,将多个身份授权和同一个账户关联。实际操作中,每个用户拥有一个全局的身份标识,然后其他关联信息通过这个全局标识进行关联,而不是把这些所有的信息放到同一个数据记录上。
4 . 多个授权标识关联到一个账户
这个星期用户通过用户名和密码登录了你的服务,可能下星期会用Google的授权进行登录。这可能造成重复账户的问题。同理,用户可能会使用多个邮箱地址来使用你的服务。如果你将用户标识和认证分开,也就是可以更容易地链接多个标识到同一用户。
后端实现需要处理用户在注册过程中意识到他的第三方授权没有关联到他们已有的账户,这时就需要让用户提供一个共用的识别标识,比如邮箱地址、电话号码或者用户名。如果系统已经存在这些标识,那么就允许用户使用第三方授权认证,并将这个新的ID关联到已有账户。
5 . 不要阻止用户使用长或复杂的密码
NIST最近更新了关于密码复杂度和强度的建议。只要你使用了比较强的加密摘要算法,那么很多问题其实都不存在。无论输入长度是多少,摘要算法总是可以产生固定长度的输出,所以用户也就可以想用多长的密码都可以。如果一定要一个确定的密码长度,只要看一下服务器允许的最大POST请求的设置。通常是1MB。别慌。
你的密码摘要只包含一小部分已知的ASCII字符。如果不是,你可以将二进制的摘要进行Base64编码。因此,理论上,你可以允许用户在密码中使用任何字符。如果有人想使用克林贡语、Emoji或者控制字符,技术上也是允许的。
6 .不要制定不合理的用户名规则
网站或者服务通常会设置一些不合理的用户名规则,比如要求用户名应该至少两个或三个字符,不允许使用隐藏字符,不允许在用户名的前后使用空格。更有甚者,会要求用户名至少是八个字符,或者很粗暴的禁止任何非7位的ASCII字符集的字母和数字。
虽然严格的用户名限制可以让开发人员轻松一些,但是这些是以用户体验为代价的,设置可能驱使用户离开。
有些情况,最好的方法是分配用户名。如果你的服务适合这种情况,那就尽量让用户名尽量简单易记,方便沟通。字母数字ID可以避免视觉上的混淆,比如“Il100”。你也可以扫描字典来确保你的密码中不含有歧义。这个规则也适用于自动生成的密码。
7 .允许用户修改用户名
很多遗留系统和任何提供邮箱账号的平台不允许用户修改用户名。虽然有很好理由禁止被释放的用户名重新使用,但是长期用户还是会想要换个用户名而不需要创建一个新的账户。
你可以允许用户使用别名,然后让用户自行选择使用哪个别名,从而可以满足用户修改用户名的需要。你可以设置一些规则,比如有些机构仅允许每年修改一次用户名,或者只显示用户的主用户名。邮箱提供方需要确保用户在取消关联某个用户名时被告知了,或者禁止完全取消关联旧的用户名。
使用恰当的规则,但要确保允许用户后续可以修改。
8 .允许用户删除他们的账户
大量的服务没有自助的方法让用户删除他们的账户和相关数据。当然,谁也不想。这些考虑需要配合你的系统安全需求,但很多受限环境会提供具体的数据留存方法。通用的解决方案是让用户设定自动删除账户的时间。
某些环境下,你可能需要依法遵循用户的要求来定期地删除他们的数据。你也可以避免在数据泄漏事件中将那些已经“关闭”的账户信息泄漏。
9 .理性决定会话长度
安全和认证的会话长度通常被过度重视了。Google花了很大的力气去确保用户是他自己,并且会依据某些事件和行为来再次确认。用户可能需要多个步骤来提升账户的安全性。
你的服务的会话可能会因为某个非关键性的分析目的而一直处于打开状态,但是需要需要设置一个阈值,当达到这个阈值时需要输入密码、第二步认证或其他认证方式。
考虑经过多长时间来再次对用户进行认证。如果用户重置了密码,需要重新验证用户。如果用户修改某些核心账户信息或者进行敏感操作时,要求用户验证或者多重认证。考虑是否允许用户可以通过多个设备和地点同时登录。
当用户的会话过期或在要求用户重新验证时,尽量不要打断用户正在进行的操作,并且保留用户未保存的数据。让人沮丧的一种情况是:用户填写完一个很长的表单并提交后,才发现他们需要重新登录 – 并且所有填写的数据都丢失了。
10 .使用2步验证
如果选择2步认证(2重授权或 2FA),需要考虑当用户账户被窃取时的实际影响。短信2FA因为很多原因,已经被NIST废弃掉了,但是仍然是一个大多数用户乐于接受的选择。尽量提供安全的2FA方案。使用第三方授权服务,并借助他们的2FA是一个省钱省力的方法。
11 .用户ID大小写不敏感
你的用户可能不在意或不记得用户名的大小写。用户名应该完全大小写不敏感。常见的做法是保存用户名和邮箱地址时转化为小写字母,检查时也都转换为小写字母。
智能电话意味着不断增长的用户设备数量。很多都支持自动纠错和自动开头字母大写。在UI级别就阻止这种行为,而且你的服务需要能够处理这种未注意到的自动大写。
12 . 构建一个安全的认证系统
如果你在使用Firebase Auth,很多的安全问题都已经自动帮你处理了。但是你的服务还是需要优化以防止被滥用。一些核心的考量包括:使用密码重置而不是密码找回,详细的账户操作记录,登录尝试频率限制,如果账户被过多次尝试登录则锁定账户,在陌生设备上首次登录时或长时间未登录的账户使用2FA。还有很多其他的方面,可以参考下面的链接。
进一步阅读:

区块链到底做了什么?

区块链不亚于人类历史上任何一个发明。

如果说互联网通过信息的可复制性打破了沟通的障碍,那么区块链则是通过算法打破了信任的障碍(或者说,某些不可复制信息的传输问题)。

二者都是利用了计算机和网络技术。

互联网之前,信息存储在每个城市的图书馆、大学里,有了互联网,再没有一个图书馆可以抗衡这个信息源,而且它只会扩张。

区块链之前,信任都在各个国家的政府、银行里,有了区块链,没有一个国家或银行能够抗衡这种信任源,而且每个人只会让区块链更强壮。

最牛逼的地方是,他们基本没有给你“倒退”的可能性,互联网我们已经可以看得出来,要么与世隔绝,要么开放,信息时代没有人敢这么做。

互联网和区块链是信息时代最强大的两个发明:

互联网重新分配信息,区块链重新分配财富。

很棒的一个TED:https://www.ted.com/talks/don_tapscott_how_the_blockchain_is_changing_money_and_business

Packagist版本不同步更新的问题

git commit -a -m ‘xxx’

git tag v1.0.0

git push origin v1.0.0