验证和授权
关于应用程序安全性，验证和授权的概念起着至关重要的作用。
观看视频以获取验证和权限的概览。
我们尚未在应用程序中配置任何权限。这意味着当前没有限制，并且所有请求仍具有整个应用程序的完全访问权限。在本课中，我们将学习如何限制对应用程序的访问。
在生产环境中，默认情况下会验证所有端点，即使未配置任何限制。验证方法可自由定制。为方便起见，支持一组开箱即用的验证方法，以涵盖最常见的场景。如果出于业务原因需要向匿名用户公开开放端点，则必须采取附加措施。本课程不涉及为生产环境配置验证。
正如我们所看到的，在开发环境中测试应用程序时不需要验证。稍后，我们将了解如何为测试环境配置验证。
关注点分离
在下文中，我们将浏览注释，您可以使用这些注释在精细级别控制对业务数据的访问。您可以将讨论的注释直接插入到定义服务的 .cds 文件中。在我们的案例中，这将是 CatalogService 的文件 cat-service.cds 和 AdminService 的文件 admin-service.cds。
但是，最佳做法是将权限注释存储在不同的 .cds 文件中，以将其与实际服务定义分开。这样可以使实际服务定义简明扼要，并且只关注结构。还允许您为权限模型提供单独的所有权和生命周期。
我们将遵循此最佳实践并创建单独的 .cds 文件，以建模 CatalogService 和 AdminService 的访问规则。我们分别调用这些文件 cat-service-auth.cds 和 admin-service-auth.cds，并将其保存在我们项目的 srv 文件夹中，就像具有服务定义的文件一样。
注意
@readonly 以及 @requires
首先，让我们查看 cat-service-auth.cds 文件，我们使用该文件控制对 CatalogService 的访问（请参阅下图）。
在此文件中，我们通过 using 指令从 CatalogService 模型中导入作者和工作簿实体的定义以及 submitOrder 操作的定义。
作者和 Books 实体通过 annotate 指令通过 @readonly 进行注释，以便限制所有用户对只读访问的访问。
注意
作为访问控制的基础，您可以设计特定于应用程序的概念角色。用户可以具有多个角色，这些角色由管理用户在平台的权限管理解决方案中进行分配。
除应用程序特定的用户角色外，CAP 还支持一些预定义的所谓伪角色，例如 authenticated-user。此角色是指已成功验证的用户。
在所示示例中，@requires 注释用于控制只有经过验证的用户才能执行 submitOrder 操作。
注意
@restrict
接下来，让我们查看 admin-service-auth.cds 文件，其中包含 AdminService 的访问控制（请参阅下图）。
在此，我们首先使用 using 指令从 AdminService 模型导入要注释的定义（作者和工作簿实体）。
作者实体使用 @(requires: 'admin') 进行注释。这确定只有具有应用程序特定管理员角色的用户才能访问作者实体。
要定义 Books 实体的权限，请使用 @restrict 注释。它指定仅允许具有应用程序特定管理员角色的用户对"工作簿"实体执行"读取"、"创建"和"更新"操作。只有具有 admin 角色的用户才允许执行 DELETE 操作，此外还限制只删除库存为 0 的书。
@restrict 注释提供了一个具有任意数量的特权对象的数组，其中每个特权对象具有以下结构：
1{ grant: <events>, to: <roles>, where: <filter-condition> }权限对象的属性定义如下：
- grant
特权适用的一个或多个事件（例如 READ、CREATE、UPDATE 和 DELETE）
- to
适用于该特权的一个或多个用户角色或伪角色（可选）
- where
进一步限制实例级别访问的过滤条件（可选）
如果至少满足其中一个权限，则请求会传递由特权数组组成的限制。
注意
注意
@requires 或 @readonly 等注释只是 @restrict 的便捷快捷方式，例如：
- @(requires: 'admin') 等同于 @(restrict: [ { grant: '*', to: 'admin' } ])
- @readonly 与 相同 @(restrict: [ { grant: 'READ' } ])
