风险名称：系统共享配置检测

风险等级：中危

检测项说明：

检测注册表项HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\LSA\\RestrictAnonymous的值，该值控制是否允许远程操作注册表

检测项目:

远程操作注册表

建议值:

1

路径:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous

建议:

建议禁止远程访问操作注册表，建议关闭

在网站开发过程中遇到上传图片等文件的功能，需要在服务器上设置该目录可写入，并且必须防止被上传 .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 来解析。

软碟通制作 Windows 系统安装盘过程：

1. 下载微软官方提供的 iso 系统镜像文件

2. 如果 U 盘容量缩水，或根本无法正常使用 U 盘，使用老毛桃还原 U 盘空间

3. 打开 UltraISO，打开要写入 U 盘的 iso 文件

4. 在菜单上选择：启动 - 写入硬盘映像...

5. 选择硬盘驱动器，格式化，写入（注意：点击“写入”是按 FAT32 重新格式化的，若要制作 NTFS 文件系统的 U 盘，请先按 NTFS 格式化，然后在此界面上点击“便捷启动”-“便捷写入”）

6. 如果 U 盘足够大，可以在 U 盘里多放几个系统镜像，双击打开另一个 iso，将所有文件和文件夹复制到 U 盘上新建的目录中。这样下次需要安装什么系统时，只要把对应的系统的文件放到 U 盘根目录，其它系统移到二级目录中即可。当然还可以往里面存放一些常用软件。

另外最好常备一个带有 PE 系统的启动盘，在旧电脑上安装旧系统时经常会用到。

如果在分区那步无法删除或创建分区（提示动态卷什么的），在确认放弃磁盘中的文件的前提下，可以使用 Shift + F10 调出命令行，键入 diskpart，列出磁盘（list disk），选择磁盘（select disk 0），清除（clean），注意 U 盘启动盘也会在列表中，勿删！

重点提前看：

https://xoyozo.net/Blog/Details/MySQL-on-Windows

Connector/Net 6.10.4（暂）不支持在 Visual Studio 2015/2017 添加 ADO.NET 实体数据模型时选择 MySQL Data Provider 数据源。并且，在编译项目时会出现“违反了继承安全性规则”的异常。

只能降回 Connector/Net 6.9.10，NuGet 中将 MySql.Data 和 MySql.Data.Entity 用 6.9.10 和 6.10.4 版本皆可（除非遇到下文中提到的异常）。

重新生成或重启 VS 使之生效。

另外，MySql.Data 和 MySql.Data.Entity 6.9.10 可以配合 EnityFramework 和 EntityFramework.zh-Hans 6.1.x 和 6.2.0 使用。

MySql.Data 和 MySql.Data.Entity 6.9.9 在创建/更新实体模型向导中会出现闪退，更换为 6.9.10 试试。

或重新安装 Connector/NET 和 MySQL for Visual Studio 并重启电脑试试。

仍然闪退，参此文：https://xoyozo.net/Blog/Details/mysql-for-vs-flashback。

重要提醒，如果在添加 EF 模型时报错：

您的项目引用了最新版的实体框架；但是，找不到进行数据连接所需的与此版本兼容的实体框架数据库提供程序。请退出向导，安装兼容提供程序，重新生成您的项目，然后再执行此操作。

那么在菜单中选择：生成 - 清理解决方案，然后直接添加数据模型。如果在添加前生成了项目（bin 目录下有相关 .dll 文件），那么将出现上述错误。

类型“MySql.Data.MySqlClient.MySqlProviderServices”违反了继承安全性规则。派生类型必须与基类型的安全可访问性匹配或者比基类型的安全可访问性低。

将 MySql.Data 和 MySql.Data.Entity 从 6.10.4 退回 6.9.10 版本即可。

以上问题出现在：

VS 15.4.*

VS 15.4.4

VS 15.4.5

----------------

VS 15.5 已经可以在 EF 向导中连接 MySQL 数据库（Connector/Net 6.10.4），但 MySql.Data.Entity 6.10.4 编译仍然出现“违反了继承安全性规则”。另：MySQL 官网下架了 Connector/Net 6.10.4，退回提供 6.9.10 版本。

2017-12-9 发布的 Connector/Net 6.10.5 仍然存在无法在 EF 向导中连接 MySQL 数据源的问题。

服务器上安装 Connector/Net 6.10.4 没有任何问题。

表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。怎么办？

更新 .edmx 文件时若提示：

生成模型时出现意外错误。有关详细信息，请参阅输出窗口。异常消息:“StrongTypingException: 表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。”。

可以通过以下方法来解决：

1，控制面板中打开“服务”（或执行命令 services.msc），重新启动“MySQL57”

2，在 MySQL 中执行：

use <<database name>>;
set global optimizer_switch='derived_merge=OFF';

如果提示“1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation”，请使用超级用户进行操作。

3，搞定，试试更新 .edmx 吧。

参考资料：https://stackoverflow.com/questions/33575109/mysql-entity-the-value-for-column-isprimarykey-in-table-tabledetails-is

这个简单的技巧用来解决使固定表头(thead)和滚动表体 (tbody) 的问题。这使得数据表更易于浏览。当用户滚动表格时，固定表头为用户所注意的列提供了上下文。看下面图示你就明白了：

默认情况下，overflow 属性不适用于表格分组元素 thead, tbody , tfoot。你可以在下面的示例中看到：

示例

为了使其工作，

第一步是：设置 tbody 为 display:block ，以便我们可以应用 height 和 overflow 属性。

下一步将是：设置thead 中的 tr元素设置为 display:block。

所以最终的CSS会是：

.fixed_header tbody{
  display:block;
  overflow:auto;
  height:200px;
  width:100%;
}
.fixed_header thead tr{
  display:block;
}

完整示例

这样，创建表格非常简单而且富有语义，并且没有依赖 JavaScript 。

经常会看到这样似错非错的提示：

当前上下文中不存在名称"__o"

The name '__o' does not exist in the current context

实际上，我没有定义任何名为 __o 的变量。

发生这种情况的原因可能是使用了类似如下的代码：

<% if(true) { %>
<%= 1 %>
<% } %>
<%= 2 %>

为了在设计界面的 <%= %> 代码块中提供智能感知，ASP.NET（VB 或 C#）会自动生成一个名为“__o”的临时变量，这在页面编译器看到第一个 <%= %> 块时就完成了。但是在这里，<%= %> 块在 if 中出现，所以当关闭 if 后再使用 <%= %> 时，变量超出了定义的范围。

if (true)
{
    object @__o;
    @__o = 1;
}
@__o = 2;

解决方法：在页面的早期添加一个虚表达式。例如：<%= "" %>。这将不会呈现任何内容，并且它将确保在任何潜在的 if（或其他范围界定）语句之前，在 Render 方法中将 __o 声明为顶级。

当然还有一种治标不治本的方法就是隐藏这些错误提示（这并不影响程序正常运行）：

点击错误列表面板左上角的过滤器按钮，CS0103，其中包含错误代码：当前上下文中不存在名称"__o"，这些错误将不再显示，您仍然可以有其他 IntelliSense 错误和警告。

上一篇介绍了如何创建用于 https 的 SSL 证书，本文讲述如何将创建好的 SSL 证书配置到 nginx 中。

导入证书

将 .key 文件和 .crt 文件上传到服务器，位置如：/etc/ssl/

配置 .conf

打开网站配置文件 *.conf，一般在 /usr/local/nginx/conf/vhost/

添加监听 443 端口：

listen 443 ssl;

添加 ssl 配置信息：

ssl_certificate /etc/ssl/yourdomain.com.crt;
ssl_certificate_key /etc/ssl/yourdomain.com.key;
ssl_prefer_server_ciphers on;

yourdomain.com.crt 和 yourdomain.com.key 改成真实的文件名

实现 http 自动跳转 https

配置非 443 端口请求跳转 443 端口访问：

if ($server_port !~ 443)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

如果要求仅将 GET/HEAD 请求自动跳转（POST 请求自动跳转会丢失表单数据），那么改成：

set $redirect_https 0;
if ($server_port !~ 443)
{
    set $redirect_https 1;
}
if ($request_method ~ ^(GET|HEAD)$)
{
    set $redirect_https "${redirect_https}2";
}
if ($redirect_https = 12)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

验证

最后来检查一下配置得对不对：https://www.geocerts.com/ssl_checker

扩展阅读

在 IIS 中部署 SSL

安装 SSL 证书遇到的一些问题

一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是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. 博客：点击打开链接

附注：

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

HTML5 Sortable 是一款使用原生 HTML5 drag 和 drop API 来对列表或网格进行排序的 jQuery 插件。

下载和使用：官网

步骤：

1、给 <ul /> 添加 sortable 样式类

2、引入 jquery.sortable.js

3、$('.sortable').sortable();

通过绑定 sortupdate 事件来获取排序后的 DOM 位置，示例：

$('.sortable').sortable().bind('sortupdate', function (event, ui) {
    var item = $(ui.item[0]);
    var prev = item.prev();

    $.post(window.location.pathname, {
        xdo: 'fn_sort',
        cid: item.data('cid'),
        prev: prev.data('cid') // 可能为 undefined
    }, function (json) {
        if (json.result.success) {
        } else {
            toastr['error'](json.result.info);
        }
    }, 'json');
});