laravel/lumen —— Artisan Console 命令行

1、 简介

laravellumen提供了artisan命令行接口,以便我们来进行命令行操作。

我们可以通过php artisan list来查看框架为我们提供了哪些接口。

也可以用help命令来查看,如何使用命令。

2、编写命令

laravel的话你可以直接使用命令行来创建命令。

你还可以使用--command参数来设置终端命令名。

这样app\Console\Commands目录下就多了SayHello这个类。

变量protected $signature = 'say:hello'; 就是刚刚设置的终端命令名。
变量protected $description = 'a test command, just say hello';是用来描述改名了作用的。

我们可以将我们想做的操作写入handle方法。

接下来我们将该命令注册到App\Console\Kernel中就可以执行了。

通过php artisan list命令可以查看到,say:hello已经注册成功。

执行命令

3、交互命令

3.1、 自定义参数

我们可以通过以下方式进行传参。

还可以让该参数可选可不选,以及定义默认的可选参数值:

使用argument方法可以来获取参数

通过php artisan say:hello cc来进行调用

还有一种传出方式,可以通过--方式来进行传参。

这种方式我们需要用option方法来接收参数。

如果--queue开关被传递,其值是true,否则其值是false

也可以将其改造成传值方式

简写方式

传数组

3.2、 输入提示

我们将命令改回say:hello不传参数形式。

输入提示分4种模式:

  • 询问
  • 密码
  • 确认
  • 选择

询问模式

不输入内容,自定会进行重试操作。

密码模式

密码模式输入字符不会再命令行中显示。但是需要开启exec的函数使用权。

确认模式

默认为no,只有输入yYyesYES才算通过

选择模式

第一种anticipate用户可以无视给出的提示,自己填写。

第二种choice,用户必须选择提示中的选项,否则失败。

3.3、 不同的输出样式

4、调用command

我们可以在routes.php中去调用命令。当然,这只是个例子,你可以在任何地方调用它。

仓库模式 —— Repository Pattern

在上一篇文章《laravel/lumen —— 面向接口编程》中,举了个RedisConfig的栗子,涉及到了仓库模式这个概念,但是还不够深入。现在特别再写一篇来讲述仓库模式的使用方式以及优势。

Repository 模式主要思想是建立一个数据操作代理层,把controller里的数据操作剥离出来,这样做有几个好处:

  • 把数据处理逻辑分离使得代码更容易维护
  • 数据处理逻辑和业务逻辑分离,可以对这两个代码分别进行测试
  • 减少代码重复
  • 降低代码出错的几率
  • controller代码的可读性大大提高

以下演示时基于lumen框架的。

一般我们都会在controller中回去数据,然后处理展示到页面。如下:

但是这段代码有几个问题:

  1. 控制层与数据层耦合
  2. 严重依赖Model
  3. 无法写单元测试

所谓控制层与数据层耦合就是目前数据来源是本地数据库,如果将来该成服务化了,数据来源将会是远程服务,这个时候我们就不得不改写这个控制层。那么久违反了开闭原则。

严重依赖Model的意思就是,如果控制层和Model由2个开发人员开发,那么控制层不得不等待Model的完成才能继续工作。

由于数据严重依赖Model层,所以无法写出各种数据格式的单元测试来进行测试。

好的单元测试时重构的基础。也就无法进行重构。

接下来我们就引入仓库模式来进行改造。这里我们会借助一些laravel/lumen框架的基本特性,比如说:服务容器,依赖注入。如果你对这些不熟悉,那么请先进行了解。

第一步:完成“仓库”

我们在app目录下建立仓库文件夹。

  • app
    • Repositories
      • Interfaces
      • Instances

Interfaces里面是“面向接口编程”的接口,Instances里面是实现接口的类。

记下来我们编码工作。先写一个ContentRepositoryInterface的接口,建立规范。
再写3个类ContentLocalRepositoryContentHttpRepository以及ContentCustomerRepository,表示三个不同数据来源:本地、远程HTTP以及自定义数据。

第二步:服务注册

1、写一个服务提供者

2、 添加到bootstrap\app.php

第三步:改造源代码

接下来我们可以正常访问了。目前在服务提供者中,注册的是ContentLocalRepository。本地获取数据。如果说Model层还未完成,我们可以切换到ContentCustomerRepository自定义数据。将来做了服务化,可以切换到ContentHttpRepository获取数据。

着一些只需要东一行代码就可以完成。完全符合开闭原则,解耦了代码,并且使得代码职责明确,容易阅读。

关于单元测试我们可以用mockery/mockery插件,模拟各种操作,来进行生产数据。

composer安装mockery/mockery

编写单元测试

使用phpunit进行测试

HTTPS证书生成和一些基础知识

HTTPS 区别于 HTTP,它多了加密(encryption),认证(verification),鉴定(identification)。它的安全源自非对称加密以及第三方的 CA 认证。

CA 数字证书认证中心

举个栗子

普通的介绍信

假设 A 公司的张三先生要到 B 公司去拜访,但是 B 公司的所有人都不认识他,他咋办捏?

常用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽……云云。

然后在信上敲上A公司的公章。

张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,而且A公司是经常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。

引入中介机构的介绍信

好,回到刚才的话题。如果和 B 公司有业务往来的公司很多,每个公司的公章都不同,那前台就要懂得分辨各种公章,非常滴麻烦。

所以,有某个中介公司 C,发现了这个商机。C公司专门开设了一项“代理公章”的业务。

今后,A 公司的业务员去B公司,需要带2个介绍信:
  介绍信1
  含有 C 公司的公章及 A 公司的公章。并且特地注明:C 公司信任A公司。
  
  介绍信2
  仅含有 A 公司的公章,然后写上:兹有张三先生前往贵公司办理业务,请给予接洽……云云。

这样不是增加麻烦了吗?有啥好处捏?

主要的好处在于,对于接待公司的前台,就不需要记住各个公司的公章分别是啥样子的;他/她只要记住中介公司 C 的公章即可。

当他/她拿到两份介绍信之后,先对“介绍信1”的 C 公章,验明正身;确认无误之后,再比对“介绍信1”和“介绍信2”的两个 A 公章是否一致。如果是一样的,那就可以证明“介绍信2”是可以信任的了。

在上面的栗子中,C公司 就是 CA认证中心。 介绍信就是CA认证。

CA 认证分为三类:

  • DV(Domain Validation),面向个体用户,安全体系相对较弱,验证方式就是向 whois 信息中的邮箱发送邮件,按照邮件内容进行验证即可通过;
  • OV(Organization Validation),面向企业用户,证书在 DV 证书验证的基础上,还需要公司的授权,CA 通过拨打信息库中公司的电话来确认;
  • EV(Extended Validation),打开 Github 的网页,你会看到 URL 地址栏展示了注册公司的信息,这会让用户产生更大的信任,这类证书的申请除了以上两个确认外,还需要公司提供金融机构的开户许可证,要求十分严格。

生成密钥、证书

具体操作前,还要先说一些基本概念:

  • .pem: 这是一个集合格式。公钥和私钥都是这个格式。为了区分一般私钥用.key后缀,公钥用.pub后缀。

  • .csr:这个后缀的全称是Certificate Signing Request,即是证书签名请求文件。有一些应用可以通过向证书颁发机构certificate-authorities提交请求,来生成这个文件。 这个文件实际的格式是 PKCS10 。它包括了证书请求的所有的相关细节信息,包括 subject ,orginataion,state,whatnot,以及证书的公钥,之后csr文件会被提交给caca在其基础上进行数字签名,将签名之后的文件返回过来,这个返回过来的文件就是公钥文件(其中包含了public key不包含private key)。这个返回回来的文件也可以有多种格式。可以用如下的命令查看相关信息openssl req -text -noout -in yourcsrfile.csr

  • .pkcs12 .pkx .p12最初被RSA定义在 Public-Key Cryptography Stantard 中,变量12表示这个是被Microsoft加强过的。这个格式同时包含公钥和私钥证书对,不同于.pem文件,这个格式的文件是被加密过的,Openssl可以把这个格式的文件转化成为同时包含公钥和私钥信息的文件:openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes

  • .crt .cer .cert 实质上是.pem(准确的说是.der)格式的文件的不同扩展。以这些后缀结尾的文件,会被windows的浏览器默认为是证书文件,而.pem不会被这样认出。

  • .der是另一种证书格式,它根据ASN1 DER 格式来存储,ASN1全称Abstract Syntax Notation One也是一种对于数据表示,编码以及传输的数据格式。.pem实际上是采用base64加密之后的.der文件。openssl也可以把.der文件转化成为.pem文件openssl x509 -inform der -in to-convert.der -out converted.pem


具体操作

第一部生成CA证书

现在目录里面会有三个文件,更具上面的基础知识的描述,可以知道这些什么是文件

第一步,为服务器端准备公钥、私钥

目录里多了2个服务端的公钥和私钥

第三步,生成服务器端证书

这次多了三个文件

另外多出来的ca.srl是什么文件呢?

是用来存储证书序列号文件的。

Nginx 部署

nginx配置的server中加上如下配置:

重启后就可以正常访问了。但是很由于CA证书是我们自己签发的,浏览器并不认可,所以会进行警告。

双向认证

在项目中为了数据传输的安全性,我们就可以加上ssl认证。比如:移动端请求服务端的认证加密,以及内部服务的认证加密都可以使用。

第一步, 既然是双向认证,那么我们同样需要为客户端生成一套密钥。

第二步,nginx启用双向认证。

第三步,客户端。

执行

但是这个时候用浏览器访问就会400错误。

这是我们可以为浏览器生成一个证书。然后让浏览器导入就可以访问了。

导入流程见下方

输入刚刚这只的密码即可

点击确认完成

刷新后,选择证书。

之后正常访问。

参考以及引用自:

  1. http://wangzhezhe.github.io/blog/2015/08/05/httpsandgolang/
  2. http://www.cnblogs.com/freespider/p/3622830.html
  3. http://www.barretlee.com/blog/2015/10/05/how-to-build-a-https-server/
  4. http://blog.csdn.net/jiangwlee/article/details/7724274