ECMall的一个登陆跳转Bug

  前几天在帮人做ECMall的易宝接口集成,第一次接触ECMall不熟悉支付插件的模式,也没时间去研究,而且这次集成的方式也不方便使用插件的模式,一时偷懒,直接在支付方式选择那写死了,支付结果返回验证也写在了同个app里,结果不知道为什么支付成功返回后老是会退出登陆,关键的问题来了,重新登陆后跳转回支付结果页面显示支付参数被篡改,仔细对比了一下支付成功返回的URL与登陆后的URL发现其中的参数原来有大写字母的,登陆成功后跳转回去的URL里的英文字母全部被转换成小写字母了,PHP变量名对大小写敏感,所以以RUL参数形式传递的数据就获取不到了,导致支付结果验证失败。

解析登陆过程代码,发现在文件app/frontend.base.php的login方法里有这么几行代码:

PHP代码
  1. /* 防止登陆成功后跳转到登陆、退出的页面 */  
  2. $ret_url = strtolower($ret_url);              
  3. if (str_replace(array('act=login''act=logout',), ''$ret_url) != $ret_url)  
  4. {  
  5.     $ret_url = SITE_URL . '/index.php';  
  6. }  

变量$ret_url是保存与传递登陆前的URL,用来登陆成功后跳转回登陆前的URL,在这里被小写化了。

将这几行代码改成这样:

PHP代码
  1. /* 防止登陆成功后跳转到登陆、退出的页面 */  
  2. if (str_replace(array('act=login''act=logout',), ''strtolower($ret_url)) != strtolower($ret_url)) {  
  3.     $ret_url = SITE_URL . '/index.php';  
  4. }  

这样一来就不会被转换成小写了。

php-cgi占用cpu 100%的故障排除方法

1、用top命令查看占用了大量CPU的进程

2、用命令ls -l /proc/进程ID/fd/查看耗时比较长的进程到底在干什么事情

3、用strace -p 进程ID 命令跟踪

4、将php-fpm.conf的超时时间设置成5s,然后超过5s的php-cgi的请求就会记录到php的慢日志中,设置如下:

XML/HTML代码
  1. <value name="request_slowlog_timeout">3s</value>  
  2. <value name="slowlog">logs/slow.log</value>  

设置完成,利用命令/usr/local/php/sbin/php-fpm restart重启php-fpm,过一会查看slow.log的内容发现如下内容:

XML/HTML代码
  1. script_filename =/htdocs/biglee.cn/test.php  
  2. [0x00007fffb060fd70] file_get_contents() /htdocs/biglee.cn/test.php:10  

这就是占用CPU的最终原因

Linux做PHP守护进程

PHP代码
  1. <?php    
  2. /*  
  3.  * Unix中 nohup 命令功能就是不挂断地运行命令,同时 nohup 把程序的所有输出到放到当前目录 nohup.out 文件中,  
  4.  * 如果文件不可写,则放到 <用户主目录>/nohup.out 文件中。那么有了这个命令以后我们php就写成shell 脚本使用  
  5.  * 循环来让我们脚本一直运行下去,不管我们终端窗口是否关闭都能够让我们php 脚本一直运行下去。  
  6.  */    
  7. #!/usr/bin/php    
  8. set_time_limit(0);    
  9. while(true){    
  10.     file_put_contents('timer.txt',date('Y-m-d H:i:s')."
    "
    ,FILE_APPEND);    
  11.     echo date("Y-m-d H:i:s"), 'OK!';    
  12.     sleep(30);    
  13. }    
 #chmod +x timer.php 
 * 让它在后台运行: 
 # nohup /var/www/html/timer.php & 
 * &符号的作用是让进程在后端挂起 
 *  
 # ps 
 * 将会在终端显示  5155 pts/1 00:00:00 timer.php 
 *  
 * 终结进程 
 # kill -9 5155 

YII架构与流程简单剖析

 为了便于理解,按YII包里的Demo中的博客项目执行的流程来解析。

YII是单入口形式,项目的所有的访问都通过一个入口文件来进行,index.php:
PHP代码
  1. <?php  
  2.   
  3. // change the following paths if necessary  
  4. $yii=dirname(__FILE__).'/../../framework/yii.php';  
  5. $config=dirname(__FILE__).'/protected/config/main.php';  
  6.   
  7. // remove the following line when in production mode  
  8. // defined('YII_DEBUG') or define('YII_DEBUG',true);  
  9.   
  10. require_once($yii);  
  11. Yii::createWebApplication($config)->run();  
入口文件的内容很简单,包含框架里的yii.php文件和项目的配置文件(一般是项目文件夹下的protected/config/main.php)。Yii继承于YiiBase,YiiBase的最后有这么几行(其中注释是我添加的)
PHP代码
  1. spl_autoload_register(array('YiiBase','autoload'));//注册__autoload()函数  
  2. require(YII_PATH.'/base/interfaces.php');//引入接口定义  
再回到入口文件上,最后一行,顾名思义就是运行WebApp,进入到YiiBase.php,有这些代码:
PHP代码
  1. public static function createWebApplication($config=null)  
  2. {  
  3.     return self::createApplication('CWebApplication',$config);  
  4. }  
  5.   
  6.   
  7. public static function createApplication($class,$config=null)  
  8. {  
  9.     return new $class($config);  
  10. }  
从这些代码可以看出入口文件里的createWebApplication($config)其实是创建了一个新的对象CWebApplication  
 Yii::createWebApplication($config)->run();等价于执行了CWebApplication($config)->run();
今天至此为止,改天继续。

 

windows,linux下SVN实现自动更新WEB目录

 通过SVN进行版本库管理,每次提交后,都要在SVN服务器更新最新上传的版本到WEB目录进行同步。操作比较烦琐,而且效率也低。使用SVN钩子脚本进行WEB目录同步,可很好的解决这方面的问题。由于测试机器与SVN库都在同一台机器里,所以处理起来比较方便。

 
svn项目下面有hooks目录,里面存放的是全部的钩子脚本的模板
 
post-commit.tmpl 为客户端commit提交后触发
 
以下是windows和linux下自动更新版本库的方法:
 
在SVN 项目版本库的存储目录下的hooks 目录,新建立一个post-commit.bat 文件:
 
windows:
 
@echo off
SET REPOS=%1
SET REV=%2
SET DIR=%REPOS%/hooks
SET PATH=%PATH%;
SET WORKING=E:/www/o135
svn update %WORKING% –username o135 –password o135123
 
注意:以上方法必须把SVN服务器安装目录下的bin加入到path路径(环境变量)中。SVN通过setup进行安装,默认会将bin目录增加到path路径中,如果通过压缩包进行安装,必须要手动增加。
 
要想知道此脚本是否出错,可在cmd命令行里输入:C:Documents and SettingsAdministrator>e:/svn/hooks/post-commit.bat  进行测试。出现以下信息则表明脚本成功执行:
 
C:Documents and SettingsAdministrator>e:/svn/hooks/post-commit.bat
正在升级 ‘E:wwwo135′:
版本 15。
 
红色部分是版本库的位置,大家按实际位置进行修改。
 
以后不管那台机器,只能通过svn commit命令,都会触发此脚本,自动同步web目录中。
 
linux:
 
linux下原理跟windows是一样的。只是新建的文件名不一样。
 
在SVN 项目版本库的存储目录下的hooks 目录,新建立一个post-commit文件:
 
vi post-commit
 
增加以下代码:
 
#!/bin/sh
WEB=/home/data/o135
export LANG=en_US.UTF-8
svn update $WEB –username o135 –password 'o135123'
 
保存,退出。。
 
给予此脚本的权限:
 
chmod 777 post-commit
 
测试一下,看脚本是否有权限问题
 
./post-commit
 
以后每次客户端提交操作,就会自动运行该脚本。

CI的一个Session丢失的Bug

  今天同组的同事跟我反映前台点击一些功能跳转到用户中心登陆后不会自动返回登陆前的页面。之前也没仔细测试,乘现在仔细调试调试。

  这个项目是基于CodeIgniter开发的,进入登陆页面时会把来源网址记录在CI的Session里,登陆成功后跳转回去,看来是记录的数据丢失了。

  CI的Session其实是将数据序列化后存在于数据库或者Cookie中,我用的是存在Cookie中,用开发者工具查看数据是在保存起来的,但是用CI的Session类读取数据就是读取不到,经过调试,初步发现原数据被清除了。进一步跟踪,发现是在检验Cookie数据的MD5值时与原值对不上,一时纳闷了,为什么会对不上呢?仔细看了下取出来的Cookie的值,发现urlencode后保存的网址数据被自动解码了,存之前的MD5是编码后的数据,取出来的是解码后的,因此对不上,CI为了安全,认为此数据被人为修改了,就销毁了它。

  这是在谷歌Chrome浏览器下出现的状况,不知道在其它浏览器下读取Cookie会不会自动解码,暂时没时间一一测试。

  找到原因,就好解决了,存数据的时候不要进行网址编码,如有必要在取出来后再进行urlencode编码。

让你的HTML5&CSS3网站在老IE中也能正常显示的3种方法

  起初,IE其实也是一款非常有进取心的浏览器。但经过一段时间的蛰伏后,它已经成为了我们生活中的一道障碍。微软现在又重新开始向其它浏览器发起挑战,但事实情况是,新版的现代IE浏览器一直滞后于谷歌浏览器和火狐浏览器。我们还不得不想办法兼容早期的IE浏览器。下面提到的三种方法能快捷轻松的让你的HTML5&CSS3网站在微软的主要浏览器中也能神奇的运行!

  htmlshiv.js

  Remy开发的HTML5shiv工具能利用Javascript在老式IE里创建main,header,footer等HTML5元素。也就是说使用Javascript能创建这些本来不存在的HTML5新元素。这是什么原理?你可能花几天也想不明白,但谁在意呢!这个脚本几乎是所有正式网站必用的js。

1
2
3
<!--[if lt IE 9]>
<script src="dist/html5shiv.js"></script>
<![endif]-->

  selectivizr.js

  Selectivizr.js是一款神奇的工具,它能提供大量IE不支持的CSS

辩PHP里include与require的区别

   无意中在网上看到文章,写的是PHP里include与require的区别,有说运行机制的,有说效率的,也有说处理方式的,我看了下2012年04月09日编译的中文版PHP手册,上面写着:

这两种结构除了在如何处理失败之外完全一样。include() 产生一个警告而 require() 则导致一个致命错误。换句话说,如果想在遇到丢失文件时停止处理页面就用 require()include() 就不是这样,脚本会继续运行。同时也要确认设置了合适的 include_path。注意在 PHP 4.3.5 之前,包含文件中的语法错误不会导致程序停止,但从此版本之后会。 

  不知道是网上文章写的时候PHP的版本对这两者的处理是有许多区别的,还是那些作者乱写。

 

 

让你忘记 Flash 的15款精彩 HTML5 游戏

   HTML5 游戏开发是一个热门的话题,开发人员和设计人员最近经常谈论到。虽然不能迅速取代 Flash 的地位,但是 HTML5 凭借它的开放性和强大的编程能力,取代 Flash 是必然的趋势。你会看到,越来越多的界面设计精美、效果很酷的 HTML5 游戏不断涌现出来。

  这篇文章推荐的15款精彩的 HTML5 游戏把技术发挥到了极致,用事实证明,HTML5 能够可以创建出好玩的游戏。赶紧来体验这些精彩的游戏吧。(温馨提示:推荐在 Chrome、Firefox、Safari 等现代浏览器中体验)

  Contre Jour

  《黑暗旅行》将把您带入一个光影交织,让人流连忘返的绝美世界,此作堪称游戏与互动艺术的完美交集。在游戏中,运用手指改变景观,帮助神秘小家伙Petit安全抵达目的地。通过拖拉,滑动和触碰一些小道具,如触角、喷气口和滑轮等来智勇闯关。

  Koubachi

  很简单的一款游戏,学习如何照顾植物,有浇水、施肥、喷洒农药等动作。

  BananaBread

  由 Mozilla 实验室出品,基于 HTML5 WebGL 的虚拟3D环境射击游戏。

  Cube

  这是基于 Google 地图的一个游戏。玩的方式是通过谷歌地图世界的立方。 

  3D Bricks

  基于 WebGL 技术实现的 3D 打砖块游戏,带给你不一样的游戏体验。

  Save the Day

  可以邀请朋友一起玩,一起互动的一款 HTML5 游戏。

  Connection

  基于 HTML5 技术实现的另一种模式的连连看游戏。

  Sand Trap

  很好玩的一款 HTML5 游戏,要把沙子都从场景中的方格内倒入下方的容器中。

  Entanglement

  Shell heroes

  场景设计很精美一款游戏,帮助乌龟为他们的国王铺设道路。

  Fluid Table Tennis

  Unsnarl it

  一款基于 HTML5 实现的解绳子游戏,来挑战一下吧。

发布于 分类 网站技术于让你忘记 Flash 的15款精彩 HTML5 游戏留下评论

Best PHP Frameworks for 2014

 The end of the year is upon us. Lots has changed in the PHP world in the past 365 days, and the PHP framework scene is more densely populated than ever. Everyone and their dog seems to have an idea of what a good framework should look like, but in the end, do we even know which frameworks actually end up being used in production projects? How many go beyond the stage of thousands of people just doing a demo app in them?

In a small survey we've held open for the past week or so (which has also been mentioned in PHP Weekly), we asked these questions to decide which frameworks deserve our attention in 2014 the most. The prerequisite for participation was merely having experience in more than one framework, seeing as it's pointless to ask someone what their favorite bar was if they've only drunk in one place.

Unfortunately, a big percentage of the answers had to be discarded due to people either refusing the notion that WordPress and similar suites aren't frameworks, or simply due to a blatant disregard of instructions – many responses were written by people who only ever worked in one framework. While their enthusiasm for this framework of choice is noteworthy and admirable, the final result which may end up being skewed by such approaches could hardly be called objective.

Results summary

After discarding the invalid responses, and manually verifying every participant, we were left with the following data:

chart

According to the results, the most promising frameworks for 2014 seem to be:

  • Laravel
  • Phalcon
  • Symfony2

Yii and CodeIgniter seem to be sharing 4th place.

After weeding out the obvious spam, the Laravel results had to be filtered the most, by far. Over half the people who voted for Laravel had zero proof of proficiency, or experience only with Laravel, and had to be discarded – despite this, it still prevailed.

When looking at the answers, on average, the Laravel community seems to mostly favor the ease of entry – virtually no learning curve. Whether that's good or bad is a discussion for another time, seeing as we ended up in this "PHP is bad" mess mostly due to a horde of newbies considering it an easy to enter market, but the excellent documentation, large scale community support and speed of development definitely work in its favor. Another frequently mentioned advantage seems to be an active and impressively alive IRC channel where help is given instantly.

An interesting misconception seems to be that Laravel is responsible for Composer. Many voters, both discarded and valid ones, mention Composer as the main advantage of Laravel, alongside Eloquent orM and the Blade template engine, which is downright odd seeing as Composer is a package manager completely oblivious to the framework it's being used with, if any. For more information, I urge the participants in question to read some of our Composer articles, like this one. Despite all this, having only tried Laravel in demo projects, the results of this survey have piqued my interest enough to build my next production project in it, powered by HHVM.

Phalcon's main advantage was performance over other frameworks and the fact that the framework is such a rounded up package (ORM, template engine, PHQL and more – all in one – little to no need for third party libs, meaning everything stays in-memory, C-based and super fast). Some of the respondents noted the fact that it's installed as an extension as an advantage, because the process of installation weeds out the hobbyists from the serious developers, a notion I personally tend to agree with. When mentioning cons, Phalcon's biggest one was also its biggest advantage – being written in C, it's nigh impossible to check under the hood.

Symfony2 is touted as the most modular and extensible of the bunch, and the most feature complete, mainly due to containing Doctrine2. Its voters, however, do seem able to admit that it's quite bloated and slow at times due to this feature-richness.

Interestingly, two ZF1 answers said they're stuck on said framework because of the work situation – their team or CTO refuses to switch to something more modern.