大多数农场软件不需要操心"企业级"这个问题。马来西亚农业的门槛低到只要有任何系统就已经领先了。WhatsApp群？那就是你的通讯层。某人电脑上的Excel文件？那就是你的数据库。
所以当我们最近和一个大客户坐下来，对话从功能转向安全和基础设施的时候，这是一个很有价值的时刻。他们喜欢他们看到的东西-收成流程、树木分析、地图视图。产品打动了他们。但当谈到身份验证、访问控制和底层运行的东西时，他们希望看到更多。
这是合理的反馈。而且它和我们路线图上已有的方向一致。只是让优先级变得更清晰了。
从共享访问到组织
DurianPro以前用的是一个简单的共享模型。一个用户和另一个用户共享访问权限。对小规模的设置来说够用-一个农场主加上几个工人。但它无法扩展，也无法让你真正控制谁能做什么。
我们用组织（Organization）替代了它。Org现在是核心实体。在它之下，有四个角色：
- Owner（所有者）：完全控制。管理管理员和组织本身。
- Admin（管理员）：整个组织范围内的读写权限。
- User（用户）：只读权限。可以查看数据但不能修改。
- Worker（工人）：隔离的读写权限，仅限于其分配的任务。
这不只是换个标签。它意味着管理员可以管理日常运营而不触碰组织级别的设置。工人可以记录收成但看不到销售数据。用户可以查看报告而不会有意外修改数据的风险。每个角色只看到他们需要的-不多不少。
而且因为系统从第一天起就为多租户设计，以后添加更多角色不需要重新架构任何东西。
工人：更安全，依然顺畅
工人入职一直是我们的设计重点。农场管理者发一个链接，工人打开，就进去了。不用下载应用、不用注册账号、不用记密码。这个流程没变。
变的是幕后发生的事。
当工人从新设备打开他们的链接时，我们现在会触发短信OTP验证。一个6位数的验证码会发送到管理员为他们注册的手机号。他们输入验证码，设备通过验证，然后正常使用。从工人的角度来看，只是第一次登录多了一步。从管理员的角度来看，这意味着完全掌握哪些设备有访问权限。
如果工人手机丢了，管理员禁用那个设备。如果有人离开农场，管理员完全撤销他们的访问权限。如果工人试图从未注册的设备登录，会被拦截直到通过验证。
核心是让管理农场的人掌控谁有访问权限、从哪里访问-同时不给工人的日常工作添麻烦。
管理员认证迁移到AWS Cognito
对于管理员和用户账户，我们将身份验证迁移到了AWS Cognito。这替代了我们早期自己搭建的认证系统。
实际意义是：现在支持多因素认证（MFA）。密码策略、令牌管理、会话处理-全部由AWS维护和更新的基础设施来处理。我们不自己造密码学轮子，也不存储密码。
对一个小团队来说，这是正确的取舍。我们获得了自己需要花几个月才能搭建和维护的安全保障，可以把工程时间集中在产品本身。
基础设施
这部分比较难写，原因显而易见。我们不会公布网络架构图。但大方向很重要，因为这是区分原型和平台的关键：
- 数据库：托管的关系型数据库，带自动备份。你的数据不是放在一台服务器上祈祷什么都别出错。
- 开发者访问：生产环境的访问不再通过SSH。我们使用可审计且受控的会话管理访问。
- 流量：应用服务器前面有负载均衡器。
- 存储：所有文件存储都是私有的，放在CDN后面。默认情况下没有任何东西是公开可访问的。
这些都不会出现在用户界面上。这就对了。基础设施应该是隐形的，直到它重要的那一刻-而当它重要的时候，你希望知道它在那里。
接下来
我们收到的反馈没有改变我们的方向。它确认了方向。我们升级的每个系统本来就在路线图上-那次对话只是让我们更清楚先专注在哪里。
我们完成了吗？没有。总会有更多需要加固、审计、改进的地方。但"我们为自己农场做的工具"和"你愿意把运营托付给的平台"之间的距离，已经缩短了很多。
如果你经营着一个大型庄园，一直在等一个认真对待安全和访问控制的农场管理软件，我们想向你展示DurianPro现在的样子。我们是一个小团队，但我们动作很快。
常见问题
这会影响现有用户吗？ 迁移到组织和Cognito已经完成。你的数据和访问权限完好无损。
可以有多个管理员吗？ 可以。Owner可以任命多个管理员，每个都有完整的读写权限。
如果工人没有注册手机号怎么办？ 管理员需要先添加他们的手机号。没有手机号，设备验证无法进行，工人会看到提示联系管理员。
MFA是强制的吗？ 可用且推荐，但不强制。我们特别建议Owner和Admin账户启用。
CJ是一位软件工程师，共同管理着马来西亚一个350棵榴莲树的庄园。他建造DurianPro是因为他需要的工具不存在-而现在他要确保它们经得起考验。