大量开发者需要在云函数/云对象等后端调用uni-id-co的API
事实上,很多开发者不打算使用uni-id-pages,只是需要一个像旧版uni-id那样的一个公共模块。
如果uni认为旧版uni-id大而全不适合所有云函数/云对象引入,那也应该是提供uni-id-common和uni-id-co两个公共模块。在全局引入uni-id-common,部分场景下引入大而全的uni-id-co公共模块。
而uni-id-co作为云对象只适合在客户端上做调用。
1)目前来看,如果开发者需要二次封装,在云函数/云对象中调用uni-id-co,发生外网调用,降低性能。
这些人正在发生外网调用、消耗性能却不自知,以不优雅的方式被迫使用uni-id-co:
https://ask.dcloud.net.cn/search/q-Y2xpZW50SW5mby51bmlQbGF0Zm9ybQ==#all
https://ask.dcloud.net.cn/search/q-dGhpcy5nZXRDbGllbnRJbmZv#all
https://ask.dcloud.net.cn/question/147975
https://ask.dcloud.net.cn/question/158754
https://ask.dcloud.net.cn/question/154519 (uni-id-co不易改造,另外客服所说的【暴露通用的登录逻辑】,也应该在后端实现)
2)客户端是不可信的,我认为可能引发安全问题。
可能遇到的问题:
1)【在不修改uni-id-co的情况下】,若开发者需要在uni-id-co云对象的API执行时,附加其他行为,会被拆分成两步或存在困难。
如:a) 用户付费后,同步调用uniIdCo.authorizeAppLogin() 授权用户登录VIP专属应用;
b) 仅限邀请注册,但邀请码只能一次有效,或发出邀请后1小时过期。
那么,用户注册的邀请码应该在后端加密,以便校验邀请码有效性和时效性,应该在后端判断再调用注册用户API;
c) 考试系统中考官为考生创建账号,调用uniIdCo.addUser();(注意:考官虽然可以调用addUser接口,但是不能任意创建用户,即创建的用户角色固定为考生,或创建的用户前缀为班级编号等等。)
d) 用户登录依据登录环境判断是否开启两步验证,等等...
2)修改uni-id-co云对象,添加验证规则,但是实际业务中只用到了uniIdCo.registerUser这一个API,那么uni-id-co是否同样臃肿?原本开发者已经有一套代码逻辑,升级新版的uni-id,需要将使用到用户接口相关代码拆分到uni-id-co云对象中?开发者频繁修改uni-id-co云对象,如何方便的进行更新?
但是如果把uni-id-co作为公共模块,调用后开发者自行在云函数/云对象中调用uni-id-co,a) 不发生外网调用,b) 代码清爽,需要时可引入uni-id-co模块,调用指定API,c) 不易发生安全问题,不需要做任何配置就能避免:(没有用到的API不会开放,被客户端调用)。
chunge404
很多东西,都是写给他们自已用的,我们拿到手花费太多时间在验证上,这行不通那行不通,说实话,一点都不高效,还不如自已写一个,但是入了坑,只是在这无效挣扎。目前我要在用户接受邀请后,写入其他的东西,或者在接受邀请前,需要一些额外的判断,这就麻烦了,在客户端跟云端来回通信几次才能实现,太特么麻烦了。一个业务逻辑比较复杂的系统,根本不适合用他们现成的东西,写出来的,大部分都是适合他们自已用的,不适合大众化。
2023-04-16 18:25