在.NETMVC5中使用严格的CSP网格视图集成

我们需要替换MVC5应用程序中使用的剑道网格视图，因为严格遵守CSP，我们正在寻找网格替换，但很难找到哪个是严格遵守CSP。任何人都可以帮忙，并建议一个网格的更换

如果您希望找到像剑道UI这样强大的东西，那是没有办法的，因为任何强大的LIB都会使用一些“CSP不安全”的构造。甚至谷歌标签管理器也需要“不安全的内联”，在某些情况下还需要“不安全的评估”

有些“CSP不安全”不是剑道的，而是第三方JS LIB。例如，由剑道使用的javascript库需要“不安全的评估”，但这是这个库的“麻烦”，而不是剑道。任何其他电网都将使用相同的lib或同等的lib，没有人确保这些电网完全“CSP安全”。 更新：详细研究表明Kendo UI确实使用了不安全的eval表达式，但JSZip.js-没有

在嵌入剑道网格时，您可能也有一些自己编写的“CSP不安全”代码

不幸的是，您没有透露您需要的“严格CSP合规性”。这大大减少了详细回答问题的机会

需要潜在的“不安全”：

• style src

  指令中的“不安全内联”，这是不可避免的

• script src

  指令中的“unsafe inline”，由于内联事件处理程序的存在，这是不容易避免的。但是这些并没有出现在每个浏览器中，并且它们的锁没有视觉效果（这需要额外的代码研究）更新：剑道UI本身不要在脚本中使用不安全的内联

• “不安全评估”在

  脚本src

  指令中，这是可以避免的-只需删除用户模板中的“导出到Excel”按钮。这是不可避免的，剑道用户界面使用了大量的

  Function（）

  结构，这些结构要求“不安全评估”

但是任何其他具有强大UI的网格（当然除了

…

和服务器端渲染）都会遇到同样的问题。 你仍然可以为剑道用户界面提供足够安全的CSP。我还会写信给JSZip开发人员（参考这个线程），也许他们可以去掉

新函数

构造。这将使剑道用户界面的CSP在未来更加安全。（请参见上文更新内容）

将一个库更改为另一个库是一种严重的时间浪费，并且没有人能保证另一个库在将来会保持“严格的CSP遵从性”

PS：在详细研究剑道UI之后，我确实更新了一些细节。这是我的错，对不起