阿里云盾安骑士管理平台提示的wordpress漏洞
 
wordpress /wp-includes/http.php文件中的wp_http_validate_url函数对输入IP验证不当,导致黑客可构造类似于012.10.10.10这样的畸形IP绕过验证,进行SSRF。
 
 
解决方案:
 
第一步、替换./wp-includes/http.php第534行的以下代码:
 
查找如下代码
$same_host = strtolower( $parsed_home[‘host’] ) === strtolower( $parsed_url[‘host’] );
替换为
$same_host = ( strtolower( $parsed_home[‘host’] ) === strtolower( $parsed_url[‘host’] ) || ‘localhost’ == strtolower($parsed_url[‘host’]));
第二步、./wp-includes/http.php第549行
 
找到如下代码
$parts = array_map( ‘intval’, explode( ‘.’, $ip ) );
并在下方新增
if( strlen( $ip ) !== strlen( implode( $parts , ‘.’ ) ) ){ return false; }
第三步、如果已经讲wordpress升级到最新版本这一步可以不做。
 
./wp-includes/http.php第549行,查找如下代码
if ( 127 === $parts[0] || 10 === $parts[0]
改成
if ( 127 === $parts[0] || 10 === $parts[0] || 0 === $parts[0]
 
 
 
 
 

 

 

更多原创内容在Adee的博客

  • HTTP服务器,默认的端口号为80/tcp(木马Executor开放此端口) 
  • HTTPS(securely transferring web pages)服务器,默认的端口号为443/tcp 443/udp 
  • Telnet(不安全的文本传送),默认端口号为23/tcp(木马Tiny Telnet Server所开放的端口) 
  • FTP,默认的端口号为21/tcp(木马Doly Trojan、Fore、Invisible FTP、WebEx、WinCrash和Blade Runner所开放的端口) 
  • TFTP(Trivial File Transfer Protocol),默认的端口号为69/udp 
  • SSH(安全登录)、SCP(文件传输)、端口重定向,默认的端口号为22/tcp 
  • SMTP Simple Mail Transfer Protocol (E-mail),默认的端口号为25/tcp(木马Antigen、Email Password Sender、Haebu Coceda、Shtrilitz Stealth、WinPC、WinSpy都开放这个端口) 
  • POP3 Post Office Protocol (E-mail) ,默认的端口号为110/tcp 
  • WebLogic,默认的端口号为7001 
  • Webshpere应用程序,默认的端口号为9080 
  • webshpere管理工具,默认的端口号为9090 
  • JBOSS,默认的端口号为8080 
  • TOMCAT,默认的端口号为8080 
  • WIN2003远程登陆,默认的端口号为3389 
  • Symantec AV/Filter for MSE,默认端口号为 8081 
  • Oracle 数据库,默认的端口号为1521 
  • ORACLE EMCTL,默认的端口号为1158 
  • Oracle XDB(XML 数据库),默认的端口号为8080 
  • Oracle XDB FTP服务,默认的端口号为2100 
  • MS SQL*SERVER数据库server,默认的端口号为1433/tcp 1433/udp 
  • MS SQL*SERVER数据库monitor,默认的端口号为1434/tcp 1434/udp

前端编写email邮件模板的注意事项

1、全局规则之一,不要写<style>标签、不要写class,所有CSS都用style属性,什么元素需要什么样式就用style写内联的CSS。
 
2、全局规则之二,少用图片,邮箱不会过滤你的img标签,但是系统往往会默认不载入陌生来信的图片,如果用了很多图片的邮件,在片没有载入的情况下,丑陋无比甚至看不清内容,没耐心的用户直接就删除了。图片上务必加上alt。
 
3、不要在style里面写float、position这些style,因为会被过滤。那么如何实现左右布局或者更复杂的布局呢?用table。
 
4、style内容里面background可以设置color,但是img会被过滤,就是说不能通过CSS来设置背景图片了。但是有一个很有意思的元素 属性,也叫background,里面可以定义一个图片路径,这是个不错的替代方案,虽然这样功能有限,比如无法定位背景图片了,有总比没有好。例如要给 一个单元格加一个背景,必须这样写:
<td background=”http://image1.koubei.com/images/common/logo_koubei.gif”></td>
 
5、div模式的邮箱不支持flash,iframe模式的有待验证。
 
最后提一句,sohu的邮箱很怪异,会在每个文本段后面加一个空格,导致原本正常的排版一行放不下而换行,从而使某些布局错乱。所以,如果你要兼容sohu邮箱的话,遇到一些紧凑的布局就要格外小心了,尽量减少文本段的数量,留足宽度。
 
更多原创内容在Adee的博客

 

相较于SVN,git是一个鼓励分支操作的版本管理工具,git操作集复杂而有效,如果详细介绍可以需要一本厚厚的书籍才能够勉强把git所有的操作命令一一介绍清楚,有兴趣的同学可以试用git -help详细了解。

以下介绍几个最常用的命令,掌握这些命令就可以满足日常的git版本管理工具的试用了。

1、查看分支
git branch                                                  //查看当前仓库本地分支
git branch -r                                              //查看当前仓库的远端分支
git branch -a                                             //查看当前仓库的所有分支(本地+远端)(常用)

2、切换分支
git checkout <name>                               //切换到名为name的分支,也可以用来从远端分支上切出本地分支(常用)

3、创建分支
git branch <name>                                   //以当前分支为主干创建名为name的分支
git branch <name_a> <name_b>              //以name_b分支为主干,创建名为name_b的分支
git checkout -b <name_a> <name_b>      //以name_b分支为主干,创建名为name_b的分支,并切换到name_b分支(常用)

4、删除分支
git branch -d <name>                              //删除名为name的分支

5、修改分支名
gitbranch -m <name_a> <name_b>          //修改name_a的分支名为name_b

6、拉取分支
git pull origin                                             //拉取当前分支的远端代码

7、合并分支
git merge <branch>                                  //合并指定分支到当前分支

8、提交代码
git add <file>…                                         //新增文件(空格分隔)
git rm <file>                                             //删除文件
git commit -m "commit messages"            //提交当前更新代码

9、推送分支到远端
git push -u origin master                            //推送当前分支到远端

10、暂存代码
git stash                                                    //暂存代码
git stash apply                                           //恢复暂存代码
git stash list                                               //暂存代码列表
git stash clear                                            //清空暂存代码列表





更多原创内容在Adee的博客

在网页预览word,PDF,excel等文档可以直接使用微软提供的文件预览,

http://view.officeapps.live.com/op/view.aspx?src=文件地址,以下提供几个案例。

–ppt
http://view.officeapps.live.com/op/view.aspx?src=http://bizimg.clewm.net/515/786/786515/1512526960910921fc14df5edba6b10bc7021fc2293291512526956.pptx

–excel
http://view.officeapps.live.com/op/view.aspx?src=http://bizimg.clewm.net/515/786/786515/151252696051431b8fe3fd46c757ed0699abe62a7da371512526957.xlsx

–word
http://view.officeapps.live.com/op/view.aspx?src=http://bizimg.clewm.net/515/786/786515/1512526960772ee6bceab391ea580a6b96bd140b389481512526959.docx

 

更多原创内容在Adee的博客

 

MyISAM、InnoDB、NDB Cluster、Maria、Falcon、Memoryt、Archive、Merge、Federated等

一、MyISAM引擎
myslq的默认存储引擎,目前使用最广泛的存储引擎之一。
它的前身是ISAM引擎,是ISAM引擎的升级版。mysql最初的一种存储引擎,甚至当时的mysql还没有存储引擎这一概念。
 
支持三种索引:
B-Tree
     所有的索引节点都按照balance tree的数据结构来存储,所有的数据节点都在叶节点
R-Tree
     R是矩形的意思,空间索引 
Full-text
     全文索引,能够解决like查询效率低的问题
以上3种最常使用的就是B-tree了。
MyISAM的数据存放格式饭呢为静态(fixed)固定长度、动态(dymanic)可变长度和压缩格式三种。这三种存放格式是可以由使用者在创建表格的时候指定的。默认都是不压缩的状态,如果没有指定存放格式的话,当表中存在可变长度的字段的时候,默认就是动态可变长度存储的,如果没有任何可变长度的字段的时候,默认就是静态固定长度的。当然也可以强制指定可变或者固定长度的数据文件存放方式,但是这样的话就会将字段的数据格式强制转换。
MySQL数据手册中也列举了会导致MyISAM存储引擎表文件损坏的情况:
     1、Mysql在做写操作的时候被终止
     2、主机崩溃
     3、硬件故障
     4、MyISAM中存在的BUG
MyISAM在某个表文件出错之后,不会影响到其他表,所以只要在线使用check table命令校验,并通过repair table命令修复他就可以了。但是不管怎么样,修复表之前都要做好备份工作。
 
二、InnoDB引擎
优点:
1、支持事物安全,实现了SQL92标准所定义的4个级别的要求:READ UNCOMMITTED、READ COMMITTED、REPEATABLE和SERIALIZABLE。
2、数据多版本读取,通过UNDO实现了数据的多版本读取,在当前事务之前未commit的所有其他事务的变更,当前事务是无法查到的
3、行锁定
4、外键引用
物理结构
1、数据文件(表数据和索引)
     Innodb的表数据和索引数据是存放在一起的。
2、日志文件
     Innodb是事务安全的存储引擎,相对与日志丢失,主机崩溃也只是一个小问题了。宕机恢复之后,Innodb完全可以通过REDO日志将数据库崩溃时已经完成但是还没来得及完全写入磁盘的数据进行Redo操作,根据undo日志将未完成的事务写入磁盘的部分进行回滚操作。
 
三、NDB引擎
Innodb和MyISAM引擎是MySQL使用最广泛的两个引擎,除了这两个之外,还有几个引擎需要我们关注一下,NDB引擎也叫NDB Cluster引擎。
MySql cluster主要就是用过NDB引擎来实现的。
一个Mysql Cluster的环境主要由负责管理各节点的manage主机、sql服务器节点、NDB数据节点组成。
每个NDB数据节点保存完整数据的一部分,并将所有的数据和索引数据加载到内存当中,当然也会将数据持久化到存储设备上。而且正常情况来讲,一个集群中,数据都会同时存在两个以上的节点里面。
 
 
四、Merge引擎
     可以简单地理解为对相同结构的MyISAM表通过一些特殊的包装对外提供一个单一的访问接口。
 
五、Memory引擎
     一个将数据存储在内存中的引擎,磁盘上仅存放了一个表结构相关信息的.frm文件。速度块,但是小号的内存多。
 
六、BDB引擎
 
 
七、CSV存储引擎
用于导出的时候,先创建一个CSV表,在里面插入相应的数据,然后导出

 

更多原创内容在Adee的博客

 

     数据库设计范式要求我们逻辑清晰、关系明确、扩展方便,就连存储的数据量也尽可能的少,在许多人的眼里,数据设计满足的范式级别越高则该设计越优秀。

 

     但是很多人都忽略了,数据库设计三大范式提出的时间是上个世纪的七十年代,它最根本的目的是让数据库尽量去除重复冗余的字段,以节约存储资源和保持数据一致性使数据易于修改。

 

     对于基于数据库性能的数据库设计来说,并不能以三大范式理论作为唯一的指导,而是更多地考虑到需求,以性能提升为根本目的来展开设计工作。

 

1、适度冗余
     比如我们查看文章的评论数据的时候,需要去评论表中查找评论内容与评论者id,然后根据评论id到用户表中查找用户数据,但是我们在这里需要的用户信息只有名字这一项,而我们却要查询整个。这样其实比较慢,如果我们将评论者的名字冗余到评论表中,虽然从数据库范式理论来看,这样的设计是不合理的。但是从系统的性能的角度来看,这种冗余是很有价值的。虽然在更新数据的逻辑上变复杂了,但是我们要从系统的整体性能来考虑,而不是单个行为的性能。首先用户修改用户名的频率是极低的,而查看评论的频率极高。整体来看,更新数据的成本增加了,但是查询的效率提高了,而且查询的频率远高于更新的频率,通过少部分操作的成本投入换取更大的性能提高,是系统性能优化中常用的策略。

 

2、大字段垂直拆分
     当一张表字段过多的时候,我们需要通过垂直分表的方式将一部分使用频率较低的字段拆分出去,如果给这张表里面所有的字段拍个被拆分的优先顺序的话,优先级最高的就是那些大字段。

 

     这条优化策略看似与上一条适度冗余相矛盾,但是垂直分表之前一定是经过相当严格的审核和评估的。

 

说回表中被拆分出去字段的优先级,为什么是大字段优先呢,因为大字段一般都是文章内容等极长的文本内容,这些字段所占的空间就一定很大!如果我们需要对这张表查询的时候,消耗的io资源会多很多。这是因为数据在数据文件中的存储都是以记录为最小单位的,这样查询的时候如果不能使用索引完成整个查询的话,就不得不读取包括大字段在内的很多数据,而大字段因为内容相比普通字段太大了,一般都占一条记录长度的90%以上。

 

     这样的场景下,我们就需要将大字段拆分出去,通过单独的表来存放。虽然会导致我们在需要查询这些大字段的内容的时候,就无法避免使用联表查询的方法来实现,这样会导致查询这些信息的时候的效率大打折扣,其实这也是我们在拆表之前所要审核与评估的最重要的一点:查询频率,如果相对于原表的其他字段来说,这个大字段的查询频率是低的的话,那还犹豫什么呢?只要保证原表与新表的数据是一一对应的关系,那对查询的效率影响是微乎其微的。

 

     在很多特别的场景下,表中某些字段访问频率较高,而其他字段访问频率较低的时候,我们就可以将低频字段拆分出去。

 

3、水平拆分
     水平拆分是很少用到的优化策略。如果使用得当的话会给我们带来很大的惊喜。

 

     打个比方,如果我们在所有用户中添加一个置顶帖的功能,一种方法是给帖子数据表添加一个type字段来标识他是普通帖子还是每次需要置顶显示的置顶帖。另外一种方法是新建一个置顶帖表,转变普通帖子为置顶帖的时候,将它的记录从帖子表转移到置顶帖表,需要发布置顶帖的时候直接在置顶帖表创建。

 

     在考虑之前确定两点:置顶帖相对于其他帖子的交互关系会很少,置顶帖相对与其他帖子来说访问频率较高。确定了这两点之后,我们就可以判断出,将置顶帖数据从普通帖子中水平拆分出来,对系统性能提升来说利大于弊。

 

     在很多情况下,基于类型的水平分拆优化对系统的性能提高都是有益无害的。

 

4、业务逻辑上的让步
     这一条最典型的例子就是实时数据到准实时数据的优化。

 

     产品经理希望在页面中展示帖子的阅读量或者是站点的访问统计数量,这一类准确性要求不是特别严格、对时间不敏感、访问频繁而且数据量较大的数据信息的时候,使用实时转准实时优化能够大幅度提升系统的稳定性。

 

     比如知乎网站的问题数量,知乎将这个数量作为北极星指标,可以想象这个数量是极大的。需要展示帖子的数量的时候,由于每一次的展示都需要请求实时数据,统计问题表中有多少条未被关闭的问题,重复访问带来了极大的资源浪费。而这个时候将这一项做成准实时的统计信息,每隔一秒或者更长时间,统计一次帖子的数量,并将这个数据保存在某个表中,等到需要查询的时候,只要访问这一条数据量极小的记录,就可以达成用户的需求。

 

     这样的数据在大家维护的系统中存在很多。这些统计的计算都会涉及大量的数据,同时也会消耗大量的计算资源,访问频率都非常的高,如果都通过实时统计,恐怕对服务器硬件是一个极大的考验。而对这些数据进行准实时的优化,流畅的页面展示性能对用户体验来说会是一个极大的提高!

 

5、合适的数据类型
     虽然现如今的存储硬件的价格已经远不如从前,但是优化数据类型依然是提高系统性能的重要手段,一方面是减少了数据的长度,查询同样数据内容时遍历的数据更少,降低IO资源的开销,另一方面则是合适的数据类型可以加速数据之间的比较。

 

以下主要列出易于混淆的整形和日期型数据类型的相关参数:

 

数据类型

 

长度

 

最小值

 

最大值

 

TINYINT

 

1

 

-128

 

127

 

SMALLINT

 

2

 

-32768

 

32767

 

MEDIUMINT

 

3

 

-8388608

 

8388607

 

INT

 

4

 

-2147483648

 

2147483647

 

BIGINT

 

8

 

-9*10^18

 

9*10^18

 

DATETIME

 

8

 

1001-01-01 00:00:00

 

9999-12-31 23:59:59

 

DATE

 

3

 

1001-01-01

 

 9999-12-31

 

TIME

 

3

 

00:00:00

 

23:59:59

 

YEAR

 

1

 

1001

 

9999

 

TIMESTAMP

 

4

 

1970-01-01 00:00:00

 


6、规范的对象命名
     实际上命名不会对系统的IO性能或者索引大小造成任何影响,但是这一块对数据库后期的维护和继续开发的影响非常大。

 

     就如同规范的命名对于代码的帮助一样,规范的字段名、表名、索引名能够避免给后来者(大部分情况下是自己)留下一个摸不着头脑的烂摊子。

 

更多原创内容在Adee的博客

 

 

 

 

 

 

在不同的语言中,打开模式几乎就是以下7种,整理一下给自己做个备忘。
r:只读方式打开,如果不存在抛出异常
r+:读写方式打开,如果不存在则抛出异常
rb:二进制打开文件
w:只写方式打开一个文件,如果文件已存在,则清空内容,否则创建文件
w+:读写方式打开一个文件,如果文件已存在,则清空内容,否则创建文件
a:只写方式打开,如果文件已存在,则在文件尾部添加内容,否则创建文件
a+:读写方式打开一个文件,如果文件已存在,则在文件尾部添加内容,否则创建文件

更多原创内容在Adee的博客