我们自己创建的这个可以注册用户的接口，去掉了权限控制 .. 这样做会遇到一些安全性的问题，比如用户在注册的时候，如果把 roles 设置成 administrator，那这个用户就会是网站的管理员 .. 不同的角色有不同的权限，如果用户是 administrator 这个角色，就表示他有管理员的相关权限 ..

在接口里，可以处理一下这种情况，比如直接忽略掉 roles 这个属性 .. 这样用户就不能给自己设置角色了 .. 或者也可以在接口的权限回调里面去处理一下 ..

先去做个实验 .. 在这个 REST 客户端里再去请求注册一个新的用户 .. 修改一下用户名 .. 还有邮件地址 ..

这次在发送的数据里面，再添加一个 roles 属性 .. 对应的值设置成 administrator .. 发送一下这个请求 ..

成功的创建了这个用户 .. 看一下返回的用户相关信息 ..

capabilities 是用户的权限 .. 你会看到用户有一大串权限 .. 因为这个用户的 roles ，也就是用户角色，现在是 administrator .. 就是管理员 ..

回到网站的管理后台 .. 刷新一下 ... 一般新注册的用户的角色会是 subscriber ，表示，订阅者 .. 不过刚才注册的这个用户的角色是 administrator，也就是管理员 ..

权限控制

下面我们再去处理一下接口的权限控制 .. 先打开核心的用户 REST 接口 .. 搜索一下 create_item_permissions_check 这个权限回调 ..

复制一下里面的代码 ..

然后把它粘贴到我们自己创建的这个接口的 create_item_permissions_check 里面 ..

这里它现在做的权限检查是用了 current_user_can ，看一下当前用户有没有 create_users 这个权限，如果没有，就返回一个 WordPress 的 Error ..

修改一下判断的这个条件 .. empty $request .. roles .. 意思就是，如果请求里面带 roles 这个属性 .. 就返回一个 WordPress 错误 ..

意思就是不让用户设置自己的用户角色 ..

测试

打开 REST 客户端 .. 重新配置一个请求 .. 修改一下注册的用户名 .. 还有邮件地址 .. 请求里带着 roles 属性 ..

发送一下这个请求 ..

这次会返回 401 错误 .. 意思就是用户未授权做这个动作 ..也就是现在用户不能再设置自己的用户角色了 ..

再试一下 .. 去掉请求里的 roles 属性 .. 再发送一下这个请求 ..

这回就会成功创建了这个新的用户 .. 在返回的新用户的相关信息里面 .. 他的 roles 就是默认的 subscriber .. 也就是订阅者 ..