在编写基于Datomic和Clojure的应用程序时，同行似乎可以不受限制地访问数据 . 如何构建一个多用户系统，用户A无法访问用户B专用的数据？
我知道我可以在Clojure中编写查询，这样只返回用户A的私有数据......但是什么阻止了恶意用户攻击二进制文件以查看用户B的私有数据？
UPDATE
根据@Thumbnail的答案和John P Hackworth博客的链接，Clojure / Datomic应用程序的状态实际上缺乏安全性 .
让我更清楚地说明我看到的问题，因为我没有看到任何解决方案，这是提出这个问题的原始问题 .
Datomic有一个数据存储，一个交易者和同行 . 对等体位于用户的计算机上，并针对来自数据存储的数据运行查询 . 我的问题是：如何限制数据存储中的数据访问 . 由于数据存储是愚蠢的，实际上只存储数据，我不知道如何提供访问控制 .
当AWS S3用作数据存储时，客户端（对等方）必须在访问S3之前进行身份验证，但一旦通过身份验证，对等方就无法访问所有数据！限制只是它运行的查询，如果用户想要获取另一个用户的数据，他们可以在客户端中更改代码二进制文件，以便查询以不同的用户名运行，对吧？要清楚......访问控制不仅仅是查询的条件吗？或者是否存在数据存储识别的用户特定连接，数据存储限制了哪些数据可见？
我错过了什么？
在像Rails这样的传统Web框架中，服务器端代码限制对数据的所有访问，并对用户进行身份验证和授权 . 用户可以更改URL或客户端代码，但除非用户提供了正确的凭据，否则服务器将不允许访问数据 .
由于Datomic中的数据存储是愚蠢的，它似乎缺乏基于每个用户限制访问的能力，并且应用程序（对等方）必须这样做 . 我不想信任用户的行为，也不想尝试获取其他用户的信息 .
一个简单的例子是银行系统 . 当然用户将被认证...但在那之后，是什么阻止他们修改客户端代码/二进制文件以更改数据查询以从数据存储中获取其他用户的帐户信息？
UPDATE - MODELS
这里有两个可能的模型，我有Datomic和Clojure如何工作......第一个是我当前的模型（在我脑海中） .
-
用户的计算机运行客户端/对等端，该客户端/对等端具有查询并完全访问数据存储，其中用户在客户端启动之前进行了身份验证，从而将用户限制为我们拥有凭据的用户 .
-
用户的计算机具有与驻留在服务器上的对等方交互的接口（webapp） . 查询在服务器上并且不能由用户修改，因此访问控制由运行对等体的服务器的安全性自身进行访问控制 .
如果第二个模型是正确的，那么我的问题就得到了解答：用户无法修改服务器代码，服务器代码包含访问控制...因此，我认为驻留在用户计算机上的“对等体”实际上驻留在应用服务器 .
3 回答
您可以使用事务功能来强制执行对等/用户的访问限制 . 您可以将描述策略的数据放入数据库，并使用事务功能强制执行它们 . 这将机制和政策转移到交易者 . 不符合标准的事务可能会失败或只是导致没有数据被处理 .
显然，您需要一些方法来保护策略数据和事务功能他们自己 .
据我所知......那远非完全......如果我错了，请纠正我......
Datomic的显着特征是查询引擎或其大部分驻留在数据库客户端中，而不是数据库服务器中 . 因此，正如您所推测的那样，任何获得对数据库客户端的编程访问的“用户”都可以使用数据库的任何内容执行他们喜欢的操作 .
另一方面，像Oracle这样的帐户系统限制了客户端访问，因此恶意用户只能，可以说，破坏他们自己的数据 .
但是，......
您的应用程序（数据库客户端）不需要（并且最好不要！）提供对任何客户端用户的开放访问 . 您需要对用户进行身份验证和授权 . 您可以向客户端用户显示代码，但如果您的应用程序是安全的，则不会对此知识进行恶意使用 .
另一个考虑因素是Datomic可以坐在SQL数据库的前面，可以构建受约束的访问 .
一个网络搜索出现了Chas . Emerick的Friend库，用于Clojure中的用户身份验证和授权 . 它还发现John P Hackworth的头脑清醒评估Clojure web security is worse than you think .
你的第二个模型是正确的 . Datomic的设计使得对等体，交易者和存储都在软件和您控制的硬件上的可信网络边界内运行 . 您的应用程序服务器运行对等库，用户通过HTTP等协议与您的应用程序服务器进行交互 . 在您的应用程序中，您应该提供某种级别的用户身份验证和授权 . 这与在Rails等框架中编写的大多数应用程序的安全模型一致（即最终用户不需要数据库权限，而是需要应用程序权限） .
Datomic提供了许多非常强大的抽象，可帮助您编写应用程序级auth（n | z）代码 . 特别是，由于事务是一等实体，因此Datomic提供了在写入时（http://docs.datomic.com/transactions.html）用任意事实（例如，负责给定事务的人员的用户名，一组组等）注释事务的能力 . . 在读取时，您可以过滤数据库值（http://docs.datomic.com/clojure/index.html#datomic.api/filter），以便只对该数据库值的查询和其他读取操作返回与给定谓词匹配的事实 . 这使您可以将authz问题保留在查询逻辑之外，并使您的安全性始终如一 .