php - 锂含量协商显示所有数据——如何过滤掉？

Question

我有 app/controllers/UsersController.php 在索引操作中执行简单的 Users::find('all');。

路径 /users/index 呈现用户数据的纯 HTML 输出。路径 /users/index.json 呈现 HTML 输出的 JSON 等价物，这很棒，除了它还公开了密码(经过哈希处理，但仍然...)。

我看到有两个选项可以避免这种情况:

1. 在我的查找器中明确指定字段。
2. 过滤 Media::render() 并取消设置任何敏感数据。

从长远来看，我觉得 #2 可能更容易维护。有什么意见吗？有第三种更好的选择吗？

这就是我实现 #2 的方式:

<?php

namespace app\controllers;

use \lithium\net\http\Media;

class UsersController extends \lithium\action\Controller {
    protected function _init() {
        Media::applyFilter('render', function($self, $params, $chain) {
            if ($params['options']['type'] === 'json') {
                foreach ($params['data']['users'] as $user) {
                    $user->set([
                        'password' => null,
                        'salt' => null
                    ]);
                }
            }
            return $chain->next($self, $params, $chain);
        });
        parent::_init();
    }
}
?>

如有任何建议，我们将不胜感激。

Answer 1

这个问题可能有很多答案和解决方法，具体取决于您的应用程序、可维护性、架构的优雅等...如果您只想删除用户密码等敏感字段，您的解决方案就可以完成这项工作。

但是!

过滤 Media::render() 似乎根本不是一个好主意。您在这里混合了关注点，最终会得到一个臃肿的过滤器，您可以在其中调整一个对象以删除您不想在 json 响应中公开的内容。

如果您每次都必须为应用程序中的每个 Controller 打点，那么使用字段可能还不够好。更糟糕的是，如果您的实体有 30 多个字段，并且根据当前用户显示不同的信息(OMG)!你最终会得到一个臃肿的 Controller ，在那里，你再次混合了关注点和责任:find() 负责读取你的数据，而 fields 只是更改数据的呈现方式(某种 View )。

所以呢？我们能做什么？

复制 Controller 逻辑
您可以通过将 Controller 中的过滤逻辑包含在 if ($this->request->is('json')) { ... } 中来分离它这意味着如果请求是 html 或 json(公共(public) api)，相同的 Controller 操作会做出不同的响应。
这也不好:)
一个稍微好一点的方法是通过复制 Controller 来拆分事情 => 第一组负责你的 json api，第二组负责响应 html 的“经典” Controller 。
您可以使用 Lithium 通过添加 controllers/api 命名空间和 reconfiguring the Dispatcher 轻松做到这一点。在 json 请求/响应的情况下使用此路径。

li3_jbuilder
在某些情况下，我对复制 Controller 不太满意。更好的方法是使用 MVC 的 V 部分，但这次是渲染 json 响应，并将它们作为一流对象处理:json View !
这可以通过调整 Media 类配置轻松完成，并具有回退机制(如果未找到 *.json.php，json_encode没有过滤字段的对象)。
我 build 了li3_jbuilder对于 Lithium，可以轻松构建 json 响应、嵌套对象、使用助手以及将“表示”方面移动到 View 层。
Jbuilder 的灵感来自 Rails 的 jbuilder .仅供引用， ruby 社区得到了RABL也是。

Presenter 模式
虽然这种方法看起来很简单，但还有另一种有趣的方法，更面向对象:使用 Presenter 模式(或 Decorator)。
用户模型与 UserPresenter 类(普通的旧 php 类)相关联，负责提供要“呈现”的对象，尤其是在 json 响应中(或应用程序中的任何位置)。
Presenter 也可以帮助您清理复杂的 View 逻辑，可测试且非常灵活。
演示者需要了解模型及其将要处理的 View ，因此您需要将它们传递给 initialize 方法并将它们分配给实例变量。
只需在 google 上搜索“Presenter pattern”或“Rails presenters”(我使用的唯一使用此模式的框架)，以了解有关该主题的更多信息