博客 (56)

在 ASP.NET Core 或 ASP.NET 5 中部署百度编辑器请跳转此文。

本文记录百度编辑器 ASP.NET 版的部署过程，对其它语言版本也有一定的参考价值。

【2020.02.21 重新整理】

下载

从 GitHub 下载最新发布版本：https://github.com/fex-team/ueditor/releases

按编码分有 gbk 和 utf8 两种版本，按服务端编程语言分有 asp、jsp、net、php 四种版本，按需下载。

目录介绍

以 v1.4.3.3 utf8-net 为例，

客户端部署

本例将上述所有目录和文件拷贝到网站目录 /libs/ueditor/ 下。

当然也可以引用 CDN 静态资源，但会遇到诸多跨域问题，不建议。

在内容编辑页面引入：

<script src="/libs/ueditor/ueditor.config.js"></script>
<script src="/libs/ueditor/ueditor.all.min.js"></script>

在内容显示页面引入：

<script src="/libs/ueditor/ueditor.parse.min.js"></script>

如需修改编辑器资源文件根路径，参 ueditor.config.js 文件内顶部文件。（一般不需要单独设置）

如果使用 CDN，那么在初始化 UE 实例的时候应配置 serverUrl 值（即 controller.ashx 所在路径）。

客户端配置

初始化 UE 实例：

var ue = UE.getEditor('tb_content', {
    // serverUrl: '/libs/ueditor/net/controller.ashx', // 指定服务端接收文件路径
    initialFrameWidth: '100%'
});

其它参数见官方文档，或 ueditor.config.js 文件。

服务端部署

net 目录是 ASP.NET 版的服务端程序，用来实现接收上传的文件等功能。

本例中在网站中的位置是 /libs/ueditor/net/。如果改动了位置，那么在初始化 UE 的时候也应该配置 serverUrl 值。

这是一个完整的 VS 项目，可以单独部署为一个网站。其中：

net/config.json  服务端配置文件
net/controller.ashx  文件上传入口
net/App_Code/CrawlerHandler.cs  远程抓图动作
net/App_Code/ListFileManager.cs  文件管理动作
net/App_Code/UploadHandler.cs  上传动作

该目录不需要转换为应用程序。

服务端配置

根据 config.json 中 *PathFormat 的默认配置，一般地，上传的图片会保存在 controller.ashx 文件所在目录（即本例中的 /libs/ueditor/）的 upload 目录中：
/libs/ueditor/upload/image/
原因是 UploadHandler.cs 中 Server.MapPath 的参数是由 *PathFormat 决定的。

以修改 config.json 中的 imagePathFormat 为例：

原值："imagePathFormat": "upload/image/{yyyy}{mm}{dd}/{time}{rand:6}"

改为："imagePathFormat": "/upload/ueditor/{yyyy}{mm}{dd}/{time}{rand:6}"

以“/”开始的路径在 Server.MapPath 时会定位到网站根目录。

此处不能以“~/”开始，因为最终在客户端显示的图片路径是 imageUrlPrefix + imagePathFormat，若其中包含符号“~”就无法正确显示。

在该配置文件中查找所有 PathFormat，按相同的规则修改。

说到客户端的图片路径，我们只要将

原值："imageUrlPrefix": "/ueditor/net/"

改为："imageUrlPrefix": ""

即可返回客户端正确的 URL。

当然也要同步修改 scrawlUrlPrefix、snapscreenUrlPrefix、catcherUrlPrefix、videoUrlPrefix、fileUrlPrefix。

特殊情况，在复制包含图片的网页内容的操作中，若图片地址带“?”等符号，会出现无法保存到磁盘的情况，需要修改以下代码：

打开  CrawlerHandler.cs 文件，找到

ServerUrl = PathFormatter.Format(Path.GetFileName(this.SourceUrl), Config.GetString("catcherPathFormat"));

替换成：

ServerUrl = PathFormatter.Format(Path.GetFileName(SourceUrl.Contains("?") ? SourceUrl.Substring(0, SourceUrl.IndexOf("?")) : SourceUrl), Config.GetString("catcherPathFormat"));

如果你将图片保存到第三方图库，那么 imageUrlPrefix 值设为相应的域名即可，如：

改为："imageUrlPrefix": "//cdn.***.com"

然后在 UploadHandler.cs 文件（用于文件上传）中找到

File.WriteAllBytes(localPath, uploadFileBytes);

在其下方插入上传到第三方图库的代码，以阿里云 OSS 为例：

// 上传到 OSS
client.PutObject(bucketName, savePath.Substring(1), localPath);

在 CrawlerHandler.cs 文件（无程抓图上传）中找到

File.WriteAllBytes(savePath, bytes);

在其下方插入上传到第三方图库的代码，以阿里云 OSS 为例：

// 上传到 OSS
client.PutObject(bucketName, ServerUrl.Substring(1), savePath);

最后有还有两个以 UrlPrefix 结尾的参数名 imageManagerUrlPrefix 和 fileManagerUrlPrefix 分别是用来列出上传目录中的图片和文件的，

对应的操作是在编辑器上的“多图上传”功能的“在线管理”，和“附件”功能的“在线附件”。

最终列出的图片路径是由 imageManagerUrlPrefix + imageManagerListPath + 图片 URL 组成的，那么：

"imageManagerListPath": "/upload/ueditor/image",

"imageManagerUrlPrefix": "",

以及：

"fileManagerListPath": "/upload/ueditor/file",

"fileManagerUrlPrefix": "",

即可。

如果是上传到第三方图库的，且图库上的文件与本地副本是一致的，那么将 imageManagerUrlPrefix 和 fileManagerUrlPrefix 设置为图库域名，

服务端仍然以 imageManagerListPath 指定的路径来查找本地文件（非图库），但客户端显示图库的文件 URL。

因此，如果文件仅存放在图库上，本地没有副本的情况就无法使用该功能了。

综上，所有的 *UrlPrefix 应该设为一致。

另外记得配置不希望被远程抓图的域名，参数 catcherLocalDomain。

服务端授权

现在来判断一下只有登录用户才允许上传。

首先打开服务端的统一入口文件 controller.ashx，

继承类“IHttpHandler”改为“IHttpHandler, System.Web.SessionState.IRequiresSessionState”，即同时继承两个类，以便可使用 Session，
找到“switch”，其上插入：

if (用户未登录) { throw new System.Exception("请登录后再试"); }

即用户已登录或 action 为获取 config 才进入 switch。然后，

else
{
    action = new NotAllowedHandler(context);
}

这里的 NotAllowedHandler 是参照 NotSupportedHandler 创建的，提示语 state 可以是“登录后才能进行此操作。”

上传目录权限设置

上传目录（即本例中的 /upload/ueditor/ 目录）应设置允许写入和禁止执行。

基本用法

设置内容：

ue.setContent("Hello world.");

获取内容：

var a = ue.getContent();

更多用法见官方文档：http://fex.baidu.com/ueditor/#api-common

其它事宜

配置上传附件的文件格式

找到文件：config.json，更改“上传文件配置”的 fileAllowFiles 项，

同时在 Web 服务器上允许这些格式的文件可访问权限。以 IIS 为例，在“MIME 类型”模块中添加扩展名。

遇到从客户端(......)中检测到有潜在危险的 Request.Form 值。请参考此文

另外，对于不支持上传 .webp 类型的图片的问题，可以作以下修改：
config.json 中搜索“".bmp"”，替换为“".bmp", ".webp"”
IIS 中选中对应网站或直接选中服务器名，打开“MIME 类型”，添加，文件扩展名为“.webp”，MIME 类型为“image/webp”

最后，为了在内容展示页面看到跟编辑器中相同的效果，请参照官方文档引用 uParse

若有插入代码，再引用：
<link href="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCoreDefault.css" rel="stylesheet" />
<script src="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCore.js"></script>

其它插件雷同。

若对编辑器的尺寸有要求，在初始化时设置即可：

var ue = UE.getEditor('tb_content', {

  initialFrameWidth: '100%',
  initialFrameHeight: 320
});

图片等附件上传到阿里云 OSS 参考此文

在 ASP.NET 网站开发过程中，若提交的表单中包含有 HTML 代码，为了安全，.NET 会自动阻止提交，并抛出异常：

从客户端(......)中检测到有潜在危险的 Request.Form 值。

以前的做法是

WebFrom：在 <%@ Page %> 中加入 ValidateRequest="false"

MVC：给 Action 加上属性 [ValidateInput(false)]

显然这会给网站带来极大的风险，不推荐！

以下做法可以完美解决这个问题。

客户端把内容进行 HTML 编码，如：

content = $("<div />").text(content).html();

服务端把内容进行 HTML 解码，如：

string title = HttpUtility.HtmlDecode(Request.Form["content"]);

版本区别

下载地址

根据下面的 SHA1 或文件名在网上搜索下载地址，下载完成后验证其 SHA1 即可。

Windows 8 (x86) - DVD (Chinese-Simplified)
文件名： cn_windows_8_x86_dvd_915414.iso
SHA1: 0C4A168E37E38EFB59E8844353B2535017CBC587


Windows 8 (x64) - DVD (Chinese-Simplified)
文件名： cn_windows_8_x64_dvd_915407.iso
SHA1: A87C4AA85D55CD83BAE9160560D1CB3319DD675C


Windows 8 Pro VL (x86) - DVD (Chinese-Simplified)
文件名： cn_windows_8_pro_vl_x86_dvd_917720.iso
SHA1: EEEF3C3F6F05115C7F7C9C1D19D6A6A6418B5059


Windows 8 Pro VL (x64) - DVD (Chinese-Simplified) 推荐
文件名： cn_windows_8_pro_vl_x64_dvd_917773.iso
SHA1: 9C4EC9FC4FB561F841E22256BC9DEA6D9D6611FF


Windows 8 Enterprise (x86) - DVD (Chinese-Simplified)
文件名： cn_windows_8_enterprise_x86_dvd_917682.iso
SHA1: 951565D8579C5912FB4A407B3B9F715FBDB77EFE


Windows 8 Enterprise (x64) - DVD (Chinese-Simplified)
文件名： cn_windows_8_enterprise_x64_dvd_917570.iso
SHA1: 1280BC3A38A7001FDE981FA2E465DEB341478667

激活方式

目前流行 KMSmicro 激活，写此文时的最新版本是 4.0，下载地址网上搜之（或联系我）。

最近开发了一款 iPhone 客户端应用，提交到 App Store，被拒绝（Rejected）。然后修复问题后再次提交，仍然被拒绝，奇怪的是 Resolution Center 中的拒绝原因跟上次一模一样。


幸好我在应用中做了记录客户端信息的功能，查看后发现，IP 来自“美国Apple公司”的启动版本竟然是第一次提交的版本。于是我登录 iTunes Connect 跟苹果客服联系，对方回复他们打开的确实是有问题那个版本。


正当迷茫之时，无意中在 iTunes Connect 看到 Binary Details 这个按钮，点进去一看明白了。原来，虽然我在 Xcode 中重新上传了源文件，但是这里看到的仍然是旧版本。于是我点右上角的“Reject This Binary”按钮，重新通过 Xcode 上传源代码，过会儿再进入 Binary Details 查看，还是没有变化。苦恼中。


是不是 Xcode 中要做什么处理呢？我是新手，只知道点菜单栏上的三角形按钮是调试，具体要怎么使用 Debug / Release / Run / Test / Profile / Analyze / Archive 还真是不太明白，于是对这些功能一阵乱点，意外发现 Organizer 的 Archives 中项目的 Creation Data 变成了刚才的时间，而且下面也多了一条记录，赶紧 Distribute！


一柱香后再回头去看看 Binary Details，终于看到新版本的信息了。


Waiting For Review 中……

asp.net开发中，经常遇到“从客户端检测到有潜在危险的Request.Form 值”错误提示，很多人给出的解决方案是：

1、web.config文档<system.web>后面加入这一句： <pages validaterequest="false"/>
示例：

<?xml version="1.0" encoding="gb2312" ?>
<configuration>
<system.web>
<pages validaterequest="false"/>
</system.web>
</configuration>

2、在*.aspx文档头的page中加入validaterequest="false",示例如下：

<%@ page validaterequest="false" language="c#" codebehind="index.aspx.cs"
    autoeventwireup="false" inherits="mybbs.webform1" %>

其实这样做是不正确的，会给程序安全带来风险。

ASP.Net 1.1后引入了对提交表单自动检查是否存在XSS(跨站脚本攻击)的能力。当用户试图用之类的输入影响页面返回结果的时候，ASP.Net的引擎会引发一个 HttpRequestValidationExceptioin。这是ASP.Net提供的一个很重要的安全特性。因为很多程序员对安全没有概念，甚至都不知道XSS这种攻击的存在，知道主动去防护的就更少了。ASP.Net在这一点上做到默认安全。这样让对安全不是很了解的程序员依旧可以写出有一定安全防护能力的网站。

但是，当我Google搜索 HttpRequestValidationException 或者 "A potentially dangerous Request.Form value was detected from the client"的时候，惊奇的发现大部分人给出的解决方案竟然是在ASP.Net页面描述中通过设置 validateRequest=false 来禁用这个特性，而不去关心那个程序员的网站是否真的不需要这个特性。看得我这叫一个胆战心惊。安全意识应该时时刻刻在每一个程序员的心里，不管你对安全的概念了解多少，一个主动的意识在脑子里，你的站点就会安全很多。

为什么很多程序员想要禁止 validateRequest 呢?有一部分是真的需要用户输入"<>"之类的字符。这就不必说了。还有一部分其实并不是用户允许输入那些容易引起XSS的字符，而是讨厌这种报错的形式，毕竟一大段英文加上一个ASP.Net典型异常错误信息，显得这个站点出错了，而不是用户输入了非法的字符，可是自己又不知道怎么不让它报错，自己来处理报错。

对于希望很好的处理这个错误信息，而不使用默认ASP.Net异常报错信息的程序员们，你们不要禁用validateRequest=false。

正确的做法是在你当前页面添加Page_Error()函数，来捕获所有页面处理过程中发生的而没有处理的异常。然后给用户一个合法的报错信息。如果当前页面没有Page_Error()，这个异常将会送到Global.asax的Application_Error()来处理，你也可以在那里写通用的异常报错处理函数。如果两个地方都没有写异常处理函数，才会显示这个默认的报错页面呢。

举例而言，处理这个异常其实只需要很简短的一小段代码就够了。在页面的Code-behind页面中加入这么一段代码：

protected void Page_Error(object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();
    if (HttpContext.Current.Server.GetLastError() is HttpRequestValidationException)
    {
        HttpContext.Current.Response.Write("请输入合法的字符串【<a href='javascript:history.back(0);'>返回</a>】");
        HttpContext.Current.Server.ClearError();
    }
}

这样这个程序就可以截获 HttpRequestValidationException 异常，而且可以按照程序员的意愿返回一个合理的报错信息。

这段代码很简单，所以我希望所有不是真的要允许用户输入之类字符的朋友，千万不要随意的禁止这个安全特性，如果只是需要异常处理，那么请用类似于上面的代码来处理即可。

而对于那些通过 明确禁止了这个特性的程序员，自己一定要明白自己在做什么，而且一定要自己手动的检查必须过滤的字符串，否则你的站点很容易引发跨站脚本攻击。

关于存在Rich Text Editor的页面应该如何处理?

如果页面有富文本编辑器的控件的，那么必然会导致有类的HTML标签提交回来。在这种情况下，我们不得不将validateRequest="false"。那么安全性怎么处理?如何在这种情况下最大限度的预防跨站脚本攻击呢?

根据微软的建议，我们应该采取安全上称为“默认禁止，显式允许”的策略。

首先，我们将输入字符串用 HttpUtility.HtmlEncode()来编码，将其中的HTML标签彻底禁止。

然后，我们再对我们所感兴趣的、并且是安全标签，通过Replace()进行替换。比如，我们希望有""标签，那么我们就将""显式的替换回""。

void submitBtn_Click(object sender, EventArgs e)
{
    //将输入字符串编码，这样所有的HTML标签都失效了。
    StringBuilder sb = new StringBuilder(HttpUtility.HtmlEncode(htmlInputTxt.Text));
    //然后我们选择性的允许<b>和<i>
    sb.Replace("&lt;b&gt;", "<b>");
    sb.Replace("&lt;/b&gt;", "</b>");
    sb.Replace("&lt;i&gt;", "<i>");
    sb.Replace("&lt;/i&gt;", "</i>");
    Response.Write(sb.ToString());
}

这样我们即允许了部分HTML标签，又禁止了危险的标签。

根据微软提供的建议，我们要慎重允许下列HTML标签，因为这些HTML标签都是有可能导致跨站脚本攻击的。

<applet>
<body>
<embed>
<frame>
<script>
<frameset>
<html>
<iframe>
<img>
<style>
<layer>
<link>
<ilayer>
<meta>
<object>

可能这里最让人不能理解的是<img>。但是，看过下列代码后，就应该明白其危险性了。

<img src="javascript:alert('hello');">