老实说,我错过了上周的许多博客文章。
我忙于做很多我的大学的东西(我的B.
Tech演讲和实习公司访问校园) 但是,我们在这里,我认为在这两周中发生的事情确实值得谈论。
所以,让我带你通过它。
我们离开的地方 至"第七周"末,我有一个工作Chrome扩展——赫克网络钱包.
它可以生成一对密码密钥,从中获取身份,与赫卡身份服务机构交谈,并在当地存储SD-JWT可验证的证书.
OID4VCI 预授权代码流工作端到端.
我很高兴它。
我没有做的是清理干净 代码奏效了,但公关却一团糟——层层的固定会相互堆叠而上,TypeScript错误悄悄地潜入,一些我的导师亚历山大正确指出的建筑决定并不完全合理.
这两周是为了修复这一切。
我从修复中学到了更多的东西 而不是第一次建造它。
GPG挑战模块和GitHub OAuth模块都生活在内部。
他的观点是简单和正确的——这些都是认证问题,它们属于......。
身份服务处应当是数据提供者的消费者,而不是数据创建地。
我读它的时候,我懂知识。
当我移动模块时,我感觉到了。
身份服务部的关系突然变得合理——这是对Auth服务部拥有的东西的只读的参考.
API边界变得更干净.
依赖的方向是有道理的。
那种事情似乎像 自行车直到你这样做, 然后你不能不看到它。
如果你在像NestJS这样的框架之上建有多功能架构: 第一个版本你写的几乎永远不对事物的住址。
这很好,只要在它被计算出来之前修好它。
克里多问题 亚历山大提出的第二件大事是关于网络钱包和克里多-TS.
目前的 PR #195 手动执行 OID4VCI 持有者流——约350行取取用电话,JWT 证明占有的建筑,和 Base64url 编码.
亚历山大的问题是:我们应该用它吗?
这会减少到~20行.
问得好 老实说,我的第一个直觉是说是的—— 克里多是这个项目所建立的框架, 是正确的抽象层, 并且用它来对待持有者是一致的。
但我先查了那个钉子 最初让我犹豫的进口问题?
完全解决了克里多0.7.0.
包里装有Vite自动取回的浏览器-场 shim.
没有黑客需要。
建筑是干净的。
启动时间是可以接受的。
持有者API () 与真正的Heka发行商进行对接是正确的工作.
但后来我检查了捆绑大小 添加后,将被克齐佩德弹出包从53KB带到了400多KB.
浏览器在弹出前要分析并执行的东西增加了7倍。
对于一个Chrome扩展弹出——一个用户每次想看到他们的证书或收到新的证书时都会打开的东西——这是一个真正的UX问题.
弹出需要一个显著的瞬间出现,就是弹出者停止使用.
所以我保留了手卷式的执行。
更需要我维持密码,但从毫秒起算,是自成一体的.
我在公关上明确记录了权衡 我不断在这个项目中重新学到的教训:正确的工具是适合它运行的制约因素的工具。
克雷多是一个伟大的框架。
它只是针对启动时间和捆绑大小并非主要关注的环境而建造的——比如服务器侧代理或本地移动应用.
不是Chrome扩展弹出。
TypeScript陷阱 这里的东西花了我大约两个小时 我想记录它给任何遇到它的人。
在捐款人证明中