优点 | 缺点 | |
大白菜 | 可还原 U 盘空间 支持 UEFI | 众多山寨产品,分不清哪个是正宗老牌,说不定还是新秀更优秀 Window 10 自带防病毒软件 Window Defender 提示发现威胁 一键制作的大白菜U盘,将 iso 拷入U盘后安装的纯净系统会被捆绑安装垃圾软件 |
老毛桃 | 可还原 U 盘空间 支持 UEFI PE 还不错 | “ISO 模式”没什么问题,但“一键制作”的是 FAT32 格式,不支持将大于 4GB 的 ISO 镜像拷贝到 U 盘 “模拟启动”可启动老毛桃界面,但直接写入硬盘映像的 U 盘无法模拟启动 卸载时,Window 10 自带防病毒软件 Window Defender 提示发现特洛伊木马 |
软碟通 UltraISO | 中规中矩 写入硬盘不会自动还原 U 盘空间 | 网上找序列号激活 |
推荐! | 开源 可同时拷入多个系统镜像文件,并支持启动时选择 可支持格式化为多种文件格式 一键制作,可升级 | 暂无 |
软碟通制作 Windows 系统安装盘过程:
下载微软官方提供的 iso 系统镜像文件
如果 U 盘容量缩水,或根本无法正常使用 U 盘,使用老毛桃还原 U 盘空间
打开 UltraISO,打开要写入 U 盘的 iso 文件
在菜单上选择:启动 - 写入硬盘映像...
选择硬盘驱动器,格式化,写入(注意:点击“写入”是按 FAT32 重新格式化的,若要制作 NTFS 文件系统的 U 盘,请先按 NTFS 格式化,然后在此界面上点击“便捷启动”-“便捷写入”)
如果 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 没有任何问题。
更新 .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 吧。
这个简单的技巧用来解决使固定表头(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
扩展阅读
一、概述
重定向常常和请求转发放在一起讨论(前者是两次不相关的请求,后者是一次请求服务器端转发),然而本文并不讨论两者的区别,而是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');
});
网站的“防跨站攻击”默认是开启的,对应网站根目录下存在 .user.ini 文件,可阻止该网站程序读写网站目录外的文件或目录。
通过 FTP 上传或通过 PHP 创建的文件(夹)的用户(组)都是 www:www,目录权限 755,文件权限 644
PHP 不需要“执行”权限,因为这个“执行”权限是针对 sh 的
因此 PHP 在该站任何位置具有写入权限
理想的权限控制是:pure-ftp 使用另外的用户(组),譬如 ftp:ftp
这样使用 www:www 的 PHP 就无法随意创建文件,只能在开放了“公共权限”中的“写入”权限的目录中创建。
查看系统用户组:cat /etc/group
查看系统用户:cut -d : -f 1 /etc/passwd
查看 pure-ftp 帮助:
/www/server/pure-ftpd/bin/pure-pw --help
修改 FTP 用户的所有者和组:
/www/server/pure-ftpd/bin/pure-pw usermod FTP用户名 -u 所有者 -g 组
重启 pure-ftp
上述命令经简单测试并没有更改 FTP 用户的所有者和组……
退而求其次的做法是通过 SSH 用 root 来上传网站程序代码,并开放上传目录的“写入”权限
还有重要的一点,在网站的配置文件中禁止这些有“写入”权限的目录中的 PHP 运行权限!(参:在 CentOS (Linux) 中设置目录写入权限,并禁止执行 php)