-GWA2新增命令行运行及NO_SQL_CHECK支持

使用中的框架才会被进化。

-GWA2 在实际部署和应用中遇到新需求，于是就增加新功能，如下两个：1）新增命令行运行模式支持；2）新增对NO_SQL_CHECK的支持，分述如下，备忘。

1. GWA2 新增对命令行运行模式的支持
如果使用-GWA2的PHP实现，可以在某些情况下，需要在PHP的命令行（command line）模式下执行某些任务程序，如下是需求场景。
有 /?mod=abc&act=read 的程序，Web访问是
http://domain/path/?mod=abc&act=read

这样可以获得程序的执行，取得预期的结果返回。这一情况是远程的，需要Web Server接转，然后交给 Mod_PHP或者FastCGI给PHP解释器去执行，然后再将结果返回给Web Server，Web Server进一步地返回给用户。这显然有点绕，如果PHP处理的业务逻辑是在后台的某项计算。应景的，就是让PHP的脚本直接在后台执行，例如，
/usr/local/php/bin/php -c /www/bin/php/php.ini “/path/index.php” “?mod=abc&act=read&fmt=json”

就可能直接和快很多，而且有些时候，Web Server和（或）Mod_PHP或FastCGI都有执行时长的限制，这对某些需要耗时的程序也不利，于是就想法设法，让基于 -GWA2 写的脚本程序，既可以在浏览器中执行，也可以通过PHP脚本执行，事情就这样成了。

主要改动是在入口程序，对于PHP 命令行的调用，构建一些基本的$_SERVER变量出来。如此以来，一段脚本程序，既可以在web上被访问，也能够在本地通过命令行来执行，也即,
http://domain/path-to-webapp/index.php?mod=abc&act=efg
shell> php “/path-to-webapp/index.php” “?mod=acd&act=efg”

2) 对NO_SQL_CHECK的支持
-GWA2 在设计时，考虑了对SQL Injection的规避，所有对每次SQL的拼接和执行，都做安全性检测，但有时候，限于Java或者PHP程序本身的问题，如
<?php

$idArr = “1, 2, 3, 4”;

$db = new MySQLi();
$bad_stmt = $db->prepare(SELECT `idAsLetters` FROM `tbl` WHERE `id` IN(?));
$bad_stmt->bind_param(“s”, $idArr);
$bad_stmt->bind_result($ias);
$bad_stmt->execute();
?>
就不能参数预期结果，取而代之的是会将整个 $idArr 视为一个 String，而不是一个list.
反向的，如果我们不这样做，而是将 id list直接放入SQL中，不使用bind_param进行变量的代入，在一些情况下也能够通过。

然而，如果where语句进一步的复杂成 where url in (URL_LIST)时，URL中可能包括?，这个字符在-GWA2的SQL检查中会被视为是待替换变量，会由此在运行时变量容器hmf中进行查找对应的参数，显然找不到，于是就会触发错误。

有鉴于此，我们在 $_CONFIG中增加了:
$conf[‘no_sql_check’] = ‘omit_sql_security_check’; # keep original form of sql in some cases, 14:24 Friday, May 20, 2016, refer: http://php.net/manual/en/mysqli-stmt.bind-param.php, “2 asb(.d o,t )han(a t)n i h e i(d.o_t)dk ¶”

当访问时，设置某个$obj为临时不检查SQL时（SQL检查前置），这不对SQL做进一步的检查，从而略过这一步骤，如

$obj->set($_CONFIG[‘no_sql_check’], true); # omit sql check
$sql = ‘select * from ‘.$obj->getTbl().’ where url in (‘.$tmpStr.’)’;
$result = $obj->execBy($sql, null);
$obj->set($_CONFIG[‘no_sql_check’], false); # restore it as check