上下文中的用户和角色
我试图了解如何为我正在编写的应用程序实现用户/角色关系。 持久层是 Google App Engine 的数据存储，它对可以执行的操作设置了一些有趣的（但通常是有益的）限制。 任何想法表示赞赏。
让事情变得非常具体可能会有所帮助。 我希望有组织、用户、测试内容和测试管理（已进行的测试的记录）。 用户可以具有参与者（考生）、测试材料贡献者或两者的角色。 用户也可以是零个或多个组织的成员。 作为参与者，用户可以查看他或她之前参加的测试。 如果另一个参与者已向用户授权，则该用户还可以查看该参与者的测试管理。 用户可以查看已公开的测试材料，并且在该用户已获得组织授权的测试的特定管理期间，他或她可以作为参与者查看受限内容。 作为组织的成员，用户可以以贡献者的角色查看受限内容，并且他或她可能也可能无法编辑该内容。 每个组织都应该有一个或多个管理员，可以确定成员是否可以查看和编辑内容并确定谁拥有管理员权限。 还应该有一个或多个应用程序范围的超级用户可以排除故障并解决问题。 组织成员可以看到相关参与者授权他们查看的测试管理，如果没有授权，他们可以看到匿名数据。 在任何其他情况下，用户都无法看到其他用户的测试结果。
由于 App Engine 数据存储区中没有联接，因此可能需要对典型 SQL 数据库进行比平常更少的规范化，以确保检查权限的查询速度很快（例如，确定是否要链接的查询）。显示）。
我的问题是：
- 我该如何继续推进？ 我应该预先花费大量时间来获得正确的模型，还是可以迭代多次并逐渐增加额外的复杂性？
- 在这种情况下，有人对如何分解事物有一些一般性的想法吗？
- 是否有任何 GAE 库能够以与这种安排兼容的方式处理角色？
I'm trying to get a sense of how to implement the user/role relationships for an application I'm writing. The persistence layer is Google App Engine's datastore, which places some interesting (but generally beneficial) constraints on what can be done. Any thoughts are appreciated.
It might be helpful to keep things very concrete. I would like there to be organizations, users, test content and test administrations (records of tests that have been taken). A user can have the role of participant (test-taker), contributor of test material or both. A user can also be a member of zero or more organizations. In the role of participant, the user can see the previous administrations of tests he or she has taken. The user can also see a test administration of another participant if that participant has given the user authorization. The user can see test material that has been made public, and he or she can see restricted content as a participant during a specific administration of a test for which that user has been authorized by an organization. As a member of an organization, the user can see restricted content in the role of contributor, and he or she might or might not also be able to edit the content. Each organization should have one or more administrators that can determine whether a member can see and edit content and determine who has admin privileges. There should also be one or more application-wide superusers that can troubleshoot and solve problems. Members of organizations can see the administrations of tests that the participants concerned have authorized them to see, and they can see anonymous data if no authorization has been given. A user cannot see the test results of another user in any other circumstances.
Since there are no joins in the App Engine datastore, it might be necessary to have things less normalized than usual for the typical SQL database in order to ensure that queries that check permissions are fast (e.g., ones that determine whether a link is to be displayed).
My questions are:
- How do I move forward on this? Should I spend a lot of time up front in order to get the model right, or can I iterate several times and gradually roll in additional complexity?
- Does anyone have some general ideas about how to break things up in this instance?
- Are there any GAE libraries that handle roles in a way that is compatible with this arrangement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不太确定我是否正确理解你的问题，但我会尽力回答：
Permission，它定义每个角色可以做什么，每个角色有零个或多个Permission> 链接。 请记住，对于 GAE 中的每个多对多关系，您需要定义一个键列表，或者一个单独的实体作为中介。I'm not quite sure I'm understanding your questions correctly, but I'll try my best to answer:
Permission, that defines what each role can do, each Role having zero or morePermissionlinks. Just remember that for each many-to-many relationship in GAE you need to either define a list of keys, or a separate entity to be the intermediary.