在 Global.asax 的 Application_Start() 方法中添加以下代码,作用是在应用程序启动时预先访问一遍所有动态页面,办法虽土,但很有效。
本代码适合 Web Forms 项目,不适合 MVC 项目;修改代码中的 domain 值为真实的网站域名
代码整理中……
在 IIS 中设置应用程序池最长时效或永不过期,则效果更佳。
在应用程序池中选中网站对应的应用程序池,在右侧“操作”窗口中选择“正在回收...”
取消“固定间隔”框中的所有选项,确定。

实践证明,近 200 个动态页面一次性访问需要耗时近 10 分钟,发布后 10 分钟内无法正常浏览网站是同样是无法忍受的。因此更改方案为:
做一个 Winform 应用程序来定时访问这些页面,30 秒一个,一个半小时能完成一个循环,对正常浏览的影响非常小。
| 发布选项 \ 项目类型 | Web 窗体网站 | Web 应用程序 (Web 窗体) | Web 应用程序 (MVC) | ASP.NET Core Web 应用程序 |
在发布期间预编译 Precompile during publishing | 若勾选,将 .cs 文件编译为 .dll | 无论是否勾选,都将 .cs 文件编译为 .dll | ||
允许更新预编译站点 Allow precompiled site to be updatable | 若不允许,则会将 .aspx 等页面也一同编译,并以内容“这是预编译工具生成的标记文件,不应删除!”代替 | |||
未进行完整的测试和分析,总结有误请指正。
在网站开发过程中遇到上传图片等文件的功能,需要在服务器上设置该目录可写入,并且必须防止被上传 .php 等可执行的脚本文件。
根据文件所有者的不同,我们分两种情况讨论:
一、程序上传的用户与执行 PHP 的用户不同(例如程序代码通过 SSH 上传(root 用户),而 PHP 以 www 身份运行)
由于 Linux 上的文件默认权限是 644,目录默认权限是 755,所以在这种情况下,PHP 不能修改 root 上传的程序文件,也不能将客户端上传的图片文件保存到服务器上。
例如我们将客户端上传的文件指定到 /upload/ 目录,那么,
第 1 步,赋予它写入权限:
chmod 777 upload递归所有子目录请加 -R 参数,但会将文件也更改为 777,赋予了执行权限,这是不建议的。文件若需写入权限请设为 666。
第 2 步,设置该目录下不允许执行 PHP:
我们无法保证客户端上传完全符合我们要求的文件,那么必须禁止任何文件的执行权限。(此处指 PHP 的执行权限,注意与 sh 执行权限的区别,后者由 chmod 命令修改)
nginx 的 .conf 文件配置示例:
location ~ /upload/.*\.(php|php5)?$
{
deny all;
}Apache 的 .htaccess 文件配置示例:
RewriteRule upload/(.*).(php)$ – [F]特别注意:上面的代码必须加在 PHP 引用配置的上方才有效(如 nginx 的 PHP 引用配置 include enable-php-**.conf;)
默认 Linux 系统是大小写敏感的,所以规则中的正则表达式无须忽略大小写(但必须与实际的目录或文件名大小写一致),因为 MIME 类型中设置的是小写的 .php,那么类似大写的 .PHP 文件是不被 php-fpm 解释的,结果是被当作普通文本返回到客户端。
提问:有些目录需要设置为可写入,但里面还有正常的 php 文件,禁止执行会有问题吗?(例如 Discuz! 的 config 目录,ThinkPHP 的 Runtime 目录)
解答:以 Discuz! 为例,config 下面虽然有 config_*.php 等配置文件,但这些文件并非直接供客户端浏览,而是被其它 .php 文件引用(include 方式、IO 方式等),当 config 目录禁止执行 PHP 后并不会对它们造成影响。
我们在开发程序的过程中应避免在允许写入的目录下放置直接供客户端浏览的 .php 文件。
二、程序上传的用户与执行 PHP 的用户相同(例如程序代码通过 FTP 上传,且和 PHP 一样,都使用 www 用户)
常见于虚拟空间。这种情况下,通过 PHP 上传的文件可以保存到该网站下面的任何目录下(甚至是网站目录之外,即传说中的跨站),原因大家都懂,默认 755 中第一个是“7”,即所有者拥有写入权限。
因此,除了做到上述设置,我们必须严格控制客户端上传文件的保存路径,做到以下几点:
必须更改客户端上传的文件名,而非直接使用原文件名;
不得从客户端文件名获取扩展名,或者只控制允许的后缀名。
最可靠的文件类型判别方式是分析文件签名,参考:文件签名表,以防篡改后缀名欺骗。
举个早期的栗子:上传文件名为 abc.asp;.jpg,未改文件名保存到服务器,浏览器直接访问该文件,IIS 6 当作 abc.asp 来解析。
首先要有个工行U盾,一台手机。
苹果用户在 App Store 中搜索 中国工商银行 和 工商银行通用U盾。
安卓用户从 m.icbc.com.cn 网站下载安装客户端。

以 iPhone 为例:
打开工行U盾 App,选择U盾厂商(我的是“天地融”,无法确定的可以在此查询)
把U盾插入手机的耳机孔,状态显示“已连接”
此时点击“查看证书”提示未安装证书
打开中国工商银行 App,进入:我的 - 安全中心 - 支付管理 - 安全介质管理 - U盾证书下载
依照提示安装证书
现在可以愉快地大额转账啦!

状态:正在连接 *.*.*.*:21...
状态:连接建立,等待欢迎消息...
响应:220-FileZilla Server
响应:220-written by Tim Kosse (tim.kosse@filezilla-project.org)
响应:220 Please visit https://filezilla-project.org/
命令:AUTH TLS
错误:无法连接到服务器
最终,没有连接到任何服务器。
服务端已允许被动连接,并且 VS 中的网站发布功能正常(FTP 方式),所以从 FileZilla 客户端入手查找问题。
在站点管理器中发现“加密”项,默认是“如果可用,使用显式的 FTP over TLS”,更改为“只使用普通 FTP (不安全)”即可连接。

这个问题一般出现在换了网络环境的情况下,研究一下 FTP over TLS 很有必要。
打开 FillZilla Server - Edit - Settings - 切换到 FTP over TLS settings 选项卡

勾选 Enable FTP over TLS support (FTPS),点击 Generate new certificate...
填写需要生成的证书信息,其中“2-Digit country code”和“Save key and certificate to this file”必填,点击 Generate certificate 完成生成证书。
完成配置后 FillZilla Server 已支持 FTPS,启动页上的警告也会随之不见:
Warning: FTP over TLS is not enabled, users cannot securely log in.
jquery.barrager.js 是一款优雅的网页弹幕插件,支持显示图片,文字以及超链接。支持速度、高度、颜色、数量等自定义。
使用方法参官方网站:http://yaseng.org/jquery.barrager.js/
jquery.barrager.min.js 会报错,改用 jquery.barrager.js(版本 1.1)
实战示例:https://xoyozo.net/Demo/DanMu
该示例重写了部分 CSS 样式。
注:info 属性支持 HTML,因此要自己过滤危险标签,建议仅保留 <img /> 标签
如果要显示在指定区域,可以使用 bottom 属性,例:
bottom: (Math.random() * (0.95 - 0.5) + 0.5) * $(window).height()建议加 loading 锁,以适应网络不通畅的环境(ajax 时间超过定时间隔会导致请求到重复的数据)
跨域环境可以使用 JSONP 来实现,服务器端需设置 Access-Control-Allow-Origin 为 *。
Session 有多种存储模式,默认是 InProc,顾名思义是“在进程内”,即在 IIS 中,随网站重启而重启,网站发布后(或改动 .dll 文件)会导致应用重新运行,Session 清空。
Session 可以使用 StateServer 来保存,需要服务器开启 ASP.NET State Service 服务,此种方式要求保存在 Session 的信息必须序列化,然后从 Session 中获取的时候也要反序列化,这就导致性能有略微的损失。
Session 还可以配置为 SQLServer,将 Session 存储在数据库中,同样需要序列化。
当配置为 Custom 时,可以在使用 Memcached、Redis 等第三方缓存技术来实现 Session 的管理,本文不作讨论。
Off 模式即关闭 Session,这种方式如果要实现用户登录功能,就必须依赖 Cookie 等来实现。
下面针对常见的三种模式进行比较:
| InProc | StateServer | SQLServer | |
| 存储位置 | 应用进程内 | ASP.NET State Service 服务 | SQL Server 数据库 |
| 远程存储 | 不支持 | 支持 | 支持 |
| 存储格式 | 任意 | 序列化的 | 序列化的 |
| 可能导致重启(丢失)的情况 | 配置文件中 processModel 标签的 memoryLimit 属性; Global.asax 或者 Web.config 文件被更改; Bin 文件夹中的 Web 程序(DLL)被修改; 杀毒软件扫描了一些 .config 文件; 系统资源紧张进行资源回收导致 IIS 进程崩溃或重启等。 | ASP.NET State Service 服务停止; | - |
| Session_End() 事件 | 有 | 无 | 无 |
| 部署难度 | 无 | 简单 | 稍复杂 |
Web.config 配置示例 (<system.web> 节点内) | <sessionState mode="InProc" /> | <sessionState mode="StateServer" /> | <sessionState mode="SQLServer" sqlConnectionString ="data source=x.x.x.x; user id=[user]; password=[pwd]" /> |
因此,如果你仅仅为了标题所述的“每次发布后丢失 Session”而烦恼,那么推荐使用 StateServer 模式来存储 Session。
注:
如果 Session 的 Key 是在应用启动时随机生成的话,使用 StateServer 和 SQLServer 还是会“丢失” Session。
这是对 Session 的配置,对 Cache 无效。
删除根目录的 PrecompiledApp.config 文件(记得备份)
在 IIS 中“重新启动”该网站
原因:之前应该是发布的时候选了“在发布期间预编译”。发布后,服务器上会有这个预编译相关的文件(包含 bin 目录下也会有),其实 Application_BeginRequest() 方法是执行的,只是重新发布后没有更新而已(猜的)。具体关于发布的配置请自行了解。
在 IIS 中编辑网站绑定时,提示“至少一个其他网站正在使用同一 HTTPS 绑定,而此绑定用另一个证书配置。确实要重用此 HTTPS 绑定并将其他网站重新指定为使用新证书吗?”,那么所有网站都必须使用同一个域名证书吗?
否。只要在绑定 https 域名的时候勾选“需要服务器名称指示”就行了。
使用证书链检测工具检测结果证书链(Certificate chain)不完整怎么办?
这个问题我在两台相同版本 CentOS 和相同版本宝塔面板的 Linux 服务器上遇到过,一台证书链完整,一台证书链不完整。
使用宝塔自带的 SSL 证书导入的方式可能出现这种情况(个例),关闭之,并手动配置 nginx 的 conf 文件;而再有一台,手动配置不生效,宝塔自带 SSL 成功,因此请自行尝试。
我也在两台相同版本的 Windows Server 2012 R2 上(IIS 8.5)遇到过,一台证书链完整,一台证书链不完整。
解决思路:在命令提示符中键入 mmc,打开:文件 - 添加/添加管理单元,选择“证书”添加,选择“计算机帐户”,确定。展开“证书”
在“个人 - 证书”中可以看到我们导入的域名证书,查看它的颁发者,确保在“中间证书颁发机构 - 证书”(或“受信任的根证书颁发机构”)中能够找到,找到后继续找该证书的颁发者,一直找到根证书。一般会有多个中间证书,形成一个完整的证书链,如果证书有缺失,那么尝试重新导入域名证书,或向供应商索要中间证书。
有任何改动后,在命令提示符中执行 iisreset 来重启 IIS(IIS 管理器中的“重新启动”可能重启得不彻底),并且找到网站 - 绑定 - 删除 https 类型的绑定并重新添加,以使证书生效。
检测证书链完整后,继续摸索过程中发现,删除某中间证书,然后在 IIS 中重新绑定,会自动生成中间证书,难道是域名证书中已经包含了中间证书和根证书等完整的证书链,还是 Windows 会自动下载安装这些证书呢?
在开发支付宝支付/微信支付时回调 Url 无法接收数据。
可能是证书链不完整,建议用工具检测:GeoCerts™ SSL Checker,并用上述方法补全。
>> 遇到新问题将不断补充本文 <<

