与发送JSON和构建HTML相比,它在Ajax中发送HTML有多危险?[复制品]

我倾向于使用以下规则:

1. 请求并返回快速代码段的HTML,然后使用客户端(静态)javascript插入它们。非常适合警报消息。

2. 请求并返回大型数据集的JSON。当您希望在客户端进行筛选、分组或排序,而不需要以不同的形式重新请求数据时,这非常有用。

3. 请求并返回大型数据集的JSON,但包含JSON记录中每个记录的(转义)HTML片段。这意味着比(2)更多的渲染时间和更多的带宽使用,但可以减少通常复杂的HTML渲染的重复。

4. 请求并返回javascript,以及 eval IT客户端。这对隐藏、显示、移动和删除等交互最有效。它也可以用于插入,但通常类型(1)或(5)更适合插入。

5. 请求并返回javascript,以及 埃瓦 它是客户端的,但在JavaScript中包含转义的HTML,因此服务器正在进行HTML呈现。

我可能最常使用5和1。

在我看来,弄清楚在后端服务器中哪些地方需要在DOM结构或CSS发生更改时进行更改将是一个更大的麻烦。

将所有这些都放在一个地方(HTML文件)可能是限制Ajax与JSON通信的最佳原因。

对于两个JSON原始HTML,您仍然担心内容是安全的,毕竟JSON都是JavaScript代码。我想,如果您不信任HTML数据的来源,那么您将面临各种跨站点脚本攻击。考虑将数据作为JSON发送,并使用类似于Yahoo UI库中的javascript模板库,请参见 http://developer.yahoo.com/yui/docs/YAHOO.lang.html#method_substitute 然后让前端人员维护模板。

我不确定我完全理解这个问题…但是…

我们使用GWT并在客户机和服务器之间发送XML。我使用GWT代码生成器实现了一个XML映射系统,因此基于对象本身(使用Java类中的注释)自动生成在XML和JavaScript对象之间转换的代码。

发送直接的HTML只会降低你的应用程序的能力,因为它不再能够以任何方式解释数据,而只是用它来更新屏幕。这也使现在需要生成HTML的服务器端变得复杂…我会认真避免这种策略。

我有一种 /task/action/parameter Javascript方面的习惯用法。 我的后端严格地返回我在JSON中需要的数据,客户机(JS)负责显示它。假设我加载了这个页面 /#/item/product/5 ,javascript知道它必须调用“item”对象,方法“product”中传递了参数5。

这对于书签链接非常有效,所以当有人决定书签时 mysite.com/#/item/product/5 每次加载页面时,它都确切知道要调用什么object..method。

我认为在安全性方面没有什么大的区别——您可以解析不安全的JSON以及不安全的HTML/JS。

更重要的是应用程序的适当分层——如果直接向页面注入HTML,则必须在业务逻辑级别创建特定于视图的代码,这对我的印象是,对于干净且易于交换的层没有好处。

只是我的2美分…

我之所以想这样做,是因为前端开发人员在每次发生dom结构/css更改时都会承受巨大的痛苦,所以现在您必须找出Javascript HTML构建过程中需要更新的地方。

你一定是做错了。

从Ajax返回的数据应该只有 语义数据 也就是说,只要布局改变就不会改变的东西。将数据转换为DOM操作最好留给母版页本身定义的javascript函数。

我做这是为了发表评论,但我正在努力。

JSON本质上是安全的,问题在于人们如何处理它。

使用eval对其进行评估是个问题,而不是格式,因为格式受到JSON规范的隐式限制。损坏的JSON会使eval不安全。所以…不要那样做。不要使用eval,使用专用的JSON解析器。

同样的逻辑也可以应用于HTML。将HTML视为简单的XML“数据”,并对其进行处理,而不是盲目地将其标记到页面中。

更难让恶作剧者通过这种方式。