php面试的总结

面试问题

1. explain

内容导航

• id

• select_type

• table

• type

• possible_keys

• key

• key_len

• ref

• rows

• Extra

环境准备

MySQL版本：

创建测试表

CREATE TABLE people(     
id bigint auto_increment primary key,     
zipcode char(32) not null default '',     
address varchar(128) not null default '',     
lastname char(64) not null default '',     
firstname char(64) not null default '',     
birthdate char(10) not null default '' );
 CREATE TABLE people_car(    
  people_id bigint,    
   plate_number varchar(16) not null default '',     
   engine_number varchar(16) not null default '',     
   lasttime timestamp );

插入测试数据

insert into people (zipcode,address,lastname,firstname,birthdate)
values ('230031','anhui','zhan','jindong','1989-09-15'), ('100000','beijing','zhang','san','1987-03-11'), ('200000','shanghai','wang','wu','1988-08-25') 
insert into people_car (people_id,plate_number,engine_number,lasttime) 
values (1,'A121311','12121313','2013-11-23 :21:12:21'), (2,'B121311','1S121313','2011-11-23 :21:12:21'), (3,'C121311','1211SAS1','2012-11-23 :21:12:21')

创建索引用来测试

alter table people add key(zipcode,firstname,lastname);

EXPLAIN 介绍

先从一个最简单的查询开始：

Query-1 explain select zipcode,firstname,lastname from people;

EXPLAIN输出结果共有id,select_type,table,type,possible_keys,key,key_len,ref,rows和Extra几列。

id

Query-2 explain select zipcode from (select * from people a) b;

id是用来顺序标识整个查询中SELELCT 语句的，通过上面这个简单的嵌套查询可以看到id越大的语句越先执行。该值可能为NULL，如果这一行用来说明的是其他行的联合结果，比如UNION语句：

Query-3 explain select * from people where zipcode = 100000 union select * from people where zipcode = 200000;

select_type

SELECT语句的类型，可以有下面几种。

SIMPLE

最简单的SELECT查询，没有使用UNION或子查询。见Query-1。

PRIMARY

在嵌套的查询中是最外层的SELECT语句，在UNION查询中是最前面的SELECT语句。见Query-2和Query-3。

UNION

UNION中第二个以及后面的SELECT语句。 见Query-3。

DERIVED

派生表SELECT语句中FROM子句中的SELECT语句。见Query-2。

UNION RESULT

一个UNION查询的结果。见Query-3。

DEPENDENT UNION

顾名思义，首先需要满足UNION的条件，及UNION中第二个以及后面的SELECT语句，同时该语句依赖外部的查询。

Query-4 explain select * from people where id in  (select id from people where zipcode = 100000 union select id from people where zipcode = 200000 );

Query-4中select id from people where zipcode = 200000的select_type为DEPENDENT UNION。你也许很奇怪这条语句并没有依赖外部的查询啊。

这里顺带说下MySQL优化器对IN操作符的优化，优化器会将IN中的uncorrelated subquery优化成一个correlated subquery（关于correlated subquery参见这里）。

SELECT ... FROM t1 WHERE t1.a IN (SELECT b FROM t2);

类似这样的语句会被重写成这样：

SELECT ... FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);

所以Query-4实际上被重写成这样：

Query-5 explain select * from people o where exists  (
select id from people where zipcode = 100000 and id = o.id union select id from people where zipcode = 200000  and id = o.id);

题外话：有时候MySQL优化器这种太过“聪明” 的做法会导致WHERE条件包含IN()的子查询语句性能有很大损失。可以参看《高性能MySQL第三版》6.5.1关联子查询一节。

SUBQUERY

子查询中第一个SELECT语句。

Query-6 explain select * from people  where id =  (select id from people where zipcode = 100000);

DEPENDENT SUBQUERY

和DEPENDENT UNION相对UNION一样。见Query-5。

除了上述几种常见的select_type之外还有一些其他的这里就不一一介绍了，不同MySQL版本也不尽相同。

table

显示的这一行信息是关于哪一张表的。有时候并不是真正的表名。

Query-7 explain select * from (select * from (select * from people a) b ) c;

可以看到如果指定了别名就显示的别名。

<derivedN>N就是id值，指该id值对应的那一步操作的结果。

还有<unionM,N>这种类型，出现在UNION语句中，见Query-4。

注意：MySQL对待这些表和普通表一样，但是这些“临时表”是没有任何索引的。

type

type列很重要，是用来说明表与表之间是如何进行关联操作的，有没有使用索引。MySQL中“关联”一词比一般意义上的要宽泛，MySQL认为任何一次查询都是一次“关联”，并不仅仅是一个查询需要两张表才叫关联，所以也可以理解MySQL是如何访问表的。主要有下面几种类别。

const

当确定最多只会有一行匹配的时候，MySQL优化器会在查询前读取它而且只读取一次，因此非常快。const只会用在将常量和主键或唯一索引进行比较时，而且是比较所有的索引字段。people表在id上有一个主键索引，在(zipcode,firstname,lastname)有一个二级索引。因此Query-8的type是const而Query-9并不是：

Query-8 explain select * from people where id=1;

Query-9 explain select * from people where zipcode = 100000;

注意下面的Query-10也不能使用const table，虽然也是主键，也只会返回一条结果。

Query-10 explain select * from people where id >2;

system

这是const连接类型的一种特例，表仅有一行满足条件。

Query-11 explain select * from (select * from people where id = 1 )b;

<derived2>已经是一个const table并且只有一条记录。

eq_ref

eq_ref类型是除了const外最好的连接类型，它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。

需要注意InnoDB和MyISAM引擎在这一点上有点差别。InnoDB当数据量比较小的情况type会是All。我们上面创建的people 和 people_car默认都是InnoDB表。

Query-12 explain select * from people a,people_car b where a.id = b.people_id;

我们创建两个MyISAM表people2和people_car2试试：

CREATE TABLE people2(     
id bigint auto_increment primary key,     
zipcode char(32) not null default '',     
address varchar(128) not null default '',     
lastname char(64) not null default '',     
firstname char(64) not null default '',     
birthdate char(10) not null default '' )
ENGINE = MyISAM; CREATE TABLE people_car2(     
people_id bigint,     
plate_number varchar(16) not null default '',     
engine_number varchar(16) not null default '',     
lasttime timestamp 
)ENGINE = MyISAM;

Query-13 explain select * from people2 a,people_car2 b where a.id = b.people_id;

我想这是InnoDB对性能权衡的一个结果。

eq_ref可以用于使用 = 操作符比较的带索引的列。比较值可以为常量或一个使用在该表前面所读取的表的列的表达式。如果关联所用的索引刚好又是主键，那么就会变成更优的const了：

Query-14 explain select * from people2 a,people_car2 b where a.id = b.people_id and b.people_id = 1;

ref

这个类型跟eq_ref不同的是，它用在关联操作只使用了索引的最左前缀，或者索引不是UNIQUE和PRIMARY KEY。ref可以用于使用=或<=>操作符的带索引的列。

为了说明我们重新建立上面的people2和people_car2表，仍然使用MyISAM但是不给id指定primary key。然后我们分别给id和people_id建立非唯一索引。

reate index people_id on people2(id); create index people_id on people_car2(people_id);

然后再执行下面的查询：

Query-15 explain select * from people2 a,people_car2 b where a.id = b.people_id and a.id > 2;

Query-16 explain select * from people2 a,people_car2 b where a.id = b.people_id and a.id = 2;

Query-17 explain select * from people2 a,people_car2 b where a.id = b.people_id;

Query-18 explain select * from people2 where id = 1;

看上面的Query-15，Query-16和Query-17，Query-18我们发现MyISAM在ref类型上的处理也是有不同策略的。

对于ref类型，在InnoDB上面执行上面三条语句结果完全一致。

fulltext

链接是使用全文索引进行的。一般我们用到的索引都是B树，这里就不举例说明了。

ref_or_null

该类型和ref类似。但是MySQL会做一个额外的搜索包含NULL列的操作。在解决子查询中经常使用该联接类型的优化。（详见这里)。

Query-19 mysql> explain select * from people2 where id = 2 or id is null;

Query-20 explain select * from people2 where id = 2 or id is not null;

注意Query-20使用的并不是ref_or_null，而且InnnoDB这次表现又不相同（数据量大的情况下有待验证）。

index_merger

该联接类型表示使用了索引合并优化方法。在这种情况下，key列包含了使用的索引的清单，key_len包含了使用的索引的最长的关键元素。关于索引合并优化看这里。

unique_subquery

该类型替换了下面形式的IN子查询的ref：

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery是一个索引查找函数，可以完全替换子查询，效率更高。

index_subquery

该联接类型类似于unique_subquery。可以替换IN子查询，但只适合下列形式的子查询中的非唯一索引：

value IN (SELECT key_column FROM single_table WHERE some_expr)

range

只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。key_len包含所使用索引的最长关键元素。在该类型中ref列为NULL。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较关键字列时，可以使用range:

Query-21 explain select * from people where id = 1 or id = 2;

注意在我的测试中：发现只有id是主键或唯一索引时type才会为range。

这里顺便挑剔下MySQL使用相同的range来表示范围查询和列表查询。

explain select * from people where id >1;

 explain select * from people where id in (1,2);

但事实上这两种情况下MySQL如何使用索引是有很大差别的：

我们不是挑剔：这两种访问效率是不同的。对于范围条件查询，MySQL无法使用范围列后面的其他索引列了，但是对于“多个等值条件查询”则没有这个限制了。

——出自《高性能MySQL第三版》

index

该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小。这个类型通常的作用是告诉我们查询是否使用索引进行排序操作。

Query-22 explain select * from people order by id;

至于什么情况下MySQL会利用索引进行排序，等有时间再仔细研究。最典型的就是order by后面跟的是主键。

ALL

最慢的一种方式，即全表扫描。

总的来说：上面几种连接类型的性能是依次递减的（system>const），不同的MySQL版本、不同的存储引擎甚至不同的数据量表现都可能不一样。

possible_keys

possible_keys列指出MySQL能使用哪个索引在该表中找到行。

key

key列显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

key_len

key_len列显示MySQL决定使用的键长度。如果键是NULL，则长度为NULL。使用的索引的长度。在不损失精确性的情况下，长度越短越好 。

ref

ref列显示使用哪个列或常数与key一起从表中选择行。

rows

rows列显示MySQL认为它执行查询时必须检查的行数。注意这是一个预估值。

Extra

Extra是EXPLAIN输出中另外一个很重要的列，该列显示MySQL在查询过程中的一些详细信息，包含的信息很多，只选择几个重点的介绍下。

Using filesort

MySQL有两种方式可以生成有序的结果，通过排序操作或者使用索引，当Extra中出现了Using filesort 说明MySQL使用了后者，但注意虽然叫filesort但并不是说明就是用了文件来进行排序，只要可能排序都是在内存里完成的。大部分情况下利用索引排序更快，所以一般这时也要考虑优化查询了。

Using temporary

说明使用了临时表，一般看到它说明查询需要优化了，就算避免不了临时表的使用也要尽量避免硬盘临时表的使用。

Not exists

MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行， 就不再搜索了。

Using index

说明查询是覆盖了索引的，这是好事情。MySQL直接从索引中过滤不需要的记录并返回命中的结果。这是MySQL服务层完成的，但无需再回表查询记录。

Using index condition

这是MySQL 5.6出来的新特性，叫做“索引条件推送”。简单说一点就是MySQL原来在索引上是不能执行如like这样的操作的，但是现在可以了，这样减少了不必要的IO操作，但是只能用在二级索引上，详情点这里。

Using where

使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。

注意：Extra列出现Using where表示MySQL服务器将存储引擎返回服务层以后再应用WHERE条件过滤。

EXPLAIN的输出内容基本介绍完了，它还有一个扩展的命令叫做EXPLAIN EXTENDED，主要是结合SHOW WARNINGS命令可以看到一些更多的信息。一个比较有用的是可以看到MySQL优化器重构后的SQL。

Ok,EXPLAIN了解就到这里，其实这些内容网上都有，只是自己实际操练下会印象更深刻。下一节会介绍SHOW PROFILE、慢查询日志以及一些第三方工具。

2. author 2.0 授权方式

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。

本文对OAuth 2.0的设计思路和运行流程，做一个简明通俗的解释，主要参考材料为RFC 6749。

一、应用场景

为了理解OAuth的适用场合，让我举一个假设的例子。

有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。那么，"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。

（3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。

（4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。

（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

二、名词定义

在详细讲解OAuth 2.0之前，需要了解几个专用名词。它们对读懂后面的讲解，尤其是几张图，至关重要。

（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。

（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。

（3）Resource Owner：资源所有者，本文中又称"用户"（user）。

（4）User Agent：用户代理，本文中就是指浏览器。

（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。

（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

知道了上面这些名词，就不难理解，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。

三、OAuth的思路

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

四、运行流程

OAuth 2.0的运行流程如下图，摘自RFC 6749。

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

下面一一讲解客户端获取授权的四种模式。

五、客户端的授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

• 授权码模式（authorization code）

• 简化模式（implicit）

• 密码模式（resource owner password credentials）

• 客户端模式（client credentials）

六、授权码模式

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

它的步骤如下：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所需要的参数。

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code"

• client_id：表示客户端的ID，必选项

• redirect_uri：表示重定向URI，可选项

• scope：表示申请的权限范围，可选项

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

 HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA           &state=xyz

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。

• code：表示上一步获得的授权码，必选项。

• redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

• client_id：表示客户端ID，必选项。

下面是一个例子。

 POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

• access_token：表示访问令牌，必选项。

• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

下面是一个例子。

      HTTP/1.1 200 OK      Content-Type: application/json;charset=UTF-8      Cache-Control: no-store      Pragma: no-cache      {        "access_token":"2YotnFZFEjr1zCsicMWpAA",        "token_type":"example",        "expires_in":3600,        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",        "example_parameter":"example_value"      }

从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

七、简化模式

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

它的步骤如下：

（A）客户端将用户导向认证服务器。

（B）用户决定是否给于客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

（F）浏览器执行上一步获得的脚本，提取出令牌。

（G）浏览器将令牌发给客户端。

下面是上面这些步骤所需要的参数。

A步骤中，客户端发出的HTTP请求，包含以下参数：

• response_type：表示授权类型，此处的值固定为"token"，必选项。

• client_id：表示客户端的ID，必选项。

• redirect_uri：表示重定向的URI，可选项。

• scope：表示权限范围，可选项。

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

     GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1     Host: server.example.com

C步骤中，认证服务器回应客户端的URI，包含以下参数：

• access_token：表示访问令牌，必选项。

• token_type：表示令牌类型，该值大小写不敏感，必选项。

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

      HTTP/1.1 302 Found      Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA                &state=xyz&token_type=example&expires_in=3600

在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。

根据上面的D步骤，下一步浏览器会访问Location指定的网址，但是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。

八、密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

它的步骤如下：

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

B步骤中，客户端发出的HTTP请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为"password"，必选项。

• username：表示用户名，必选项。

• password：表示用户的密码，必选项。

• scope：表示权限范围，可选项。

下面是一个例子。

      POST /token HTTP/1.1      Host: server.example.com      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW      Content-Type: application/x-www-form-urlencoded      grant_type=password&username=johndoe&password=A3ddj3w

C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

      HTTP/1.1 200 OK      Content-Type: application/json;charset=UTF-8      Cache-Control: no-store      Pragma: no-cache      {        "access_token":"2YotnFZFEjr1zCsicMWpAA",        "token_type":"example",        "expires_in":3600,        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",        "example_parameter":"example_value"      }

上面代码中，各个参数的含义参见《授权码模式》一节。

整个过程中，客户端不得保存用户的密码。

九、客户端模式

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

它的步骤如下：

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

A步骤中，客户端发出的HTTP请求，包含以下参数：

• granttype：表示授权类型，此处的值固定为"clientcredentials"，必选项。

• scope：表示权限范围，可选项。

      POST /token HTTP/1.1      Host: server.example.com      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW      Content-Type: application/x-www-form-urlencoded      grant_type=client_credentials

认证服务器必须以某种方式，验证客户端身份。

B步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

      HTTP/1.1 200 OK      Content-Type: application/json;charset=UTF-8      Cache-Control: no-store      Pragma: no-cache      {        "access_token":"2YotnFZFEjr1zCsicMWpAA",        "token_type":"example",        "expires_in":3600,        "example_parameter":"example_value"      }

上面代码中，各个参数的含义参见《授权码模式》一节。

十、更新令牌

如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌。

客户端发出更新令牌的HTTP请求，包含以下参数：

• granttype：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。

• refresh_token：表示早前收到的更新令牌，必选项。

• scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

下面是一个例子。

      POST /token HTTP/1.1      
      Host: server.example.com      
      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW      
      Content-Type: application/x-www-form-urlencoded      
      grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

（完）

3. yii 配置文件

yii2框架的安装我们在之前文章中已经提到下面我们开始了解YII2框架

强大的YII2框架网上指南：http://www.yii-china.com/doc/detail/1.html?postid=278或者

http://www.yiichina.com/doc/guide/2.0

Yii2的应用结构：

目录篇：

advance版本的特点是：根目录下预先分配了三个模块，分别是前台、后台、控制台模块。1.backend它主要用于管理后台，网站管理员来管理整个系统。

assets 目录用于存放前端资源包PHP类。 这里不需要了解什么是前端资源包，只要大致知道是用于管理CSS、js等前端资源就可以了。config 用于存放本应用的配置文件，包含主配置文件 main.php 和全局参数配置文件 params.php 。models views controllers 3个目录分别用于存放数据模型类、视图文件、控制器类。这个是我们编码的核心，也是我们工作最多的目录。widgets 目录用于存放一些常用的小挂件的类文件。tests 目录用于存放测试类。web 目录从名字可以看出，这是一个对于Web服务器可以访问的目录。 除了这一目录，其他所有的目录不应对Web用户暴露出来。这是安全的需要。runtime 这个目录是要求权限为 chmod 777 ，即允许Web服务器具有完全的权限， 因为可能会涉及到写入临时文件等。 但是一个目录并未对Web用户可见。也就是说，权限给了，但是并不是Web用户可以访问到的。

2.frontend
我们的目标最终用户提供的主要接口的前端应用。其实，前台和后台是一样的，只是我们逻辑上的一个划分.。
好了，现在问题来了。对于 frontend backend console 等独立的应用而言， 他们的内容放在各自的目录下面，他们的运作必然用到Yii框架等 vendor 中的程序。 他们是如何关联起来的？这个秘密，或者说整个Yii应用的目录结构的秘密， 就包含在一个传说中的称为入口文件的地方。

<?phpdefined('YII_DEBUG') or define('YII_DEBUG', true);

defined('YII_ENV') or define('YII_ENV', 'dev');

require(__DIR__ . '/../../vendor/autoload.php');

require(__DIR__ . '/../../vendor/yiisoft/yii2/Yii.php');

require(__DIR__ . '/../../common/config/bootstrap.php');

require(__DIR__ . '/../config/bootstrap.php');

$config = yii\helpers\ArrayHelper::merge(

require(__DIR__ . '/../../common/config/main.php'),

require(__DIR__ . '/../../common/config/main-local.php'),

require(__DIR__ . '/../config/main.php'),

require(__DIR__ . '/../config/main-local.php'));

$application = new yii\web\Application($config);$application->run();

3.console控制台应用程序包含系统所需要的控制台命令的。



下面是全局公共文件夹4.common

其中：

• config 就是通用的配置，这些配置将作用于前后台和命令行。

• mail 就是应用的前后台和命令行的与邮件相关的布局文件等。

• models 就是前后台和命令行都可能用到的数据模型。 这也是 common 中最主要的部分。

公共的目录(Common)中包含的文件用于其它应用程序之间共享。例如，每一个应用程序可能需要访问该数据库的使用 ActiveRecord。因此，我们可以将AR模型类放置在公共(common)的目录下。同样，如果在多个应用程序中使用了一些辅助(helper )或部件类(widget )，我们也应该把这些放置在公共目录(common)下，以避免重复的代码。 正如我们将很快解释，应用程序也可以共享一部分的共用配置。因此，我们还可以存储config目录下共同的常见配置。
当开发一个大型项目开发周期长，我们需要不断调整数据库结构。出于这个原因，我们还可以使用数据库迁移(DB migrations )功能来保持跟踪数据库的变化。我们将所有 DB migrations(数据库迁移)目录同样都放在公共(common)目录下面。

5.environment每个Yii环境就是一组配置文件， 包含了入口脚本 index.php和各类配置文件。 其实他们都放在/environments 目录下面.

从上面的目录结构图中，可以看到，环境目录下有3个东东：

• 目录 dev

• 目录 prod

• 文件 index.php

其中， dev 和 prod 结构相同，分别又包含了4个目录和1个文件：

• frontend 目录，用于前台的应用，包含了存放配置文件的 config 目录和存放web入口脚本的web 目录

• backend 目录，用于后台应用，内容与 frontend 相同

• console 目录，用于命令行应用，仅包含了 config 目录，因为命令行应用不需要web入口脚本， 因此没有 web 目录。

• common 目录，用于各web应用和命令行应用通用的环境配置，仅包含了 config 目录， 因为不同应用不可能共用相同的入口脚本。 注意这个 common 的层级低于环境的层级，也就是说，他的通用，仅是某一环境下通用，并非所有环境下通用。

• yii 文件，是命令行应用的入口脚本文件。

对于分散于各处的 web 和 config 目录而言，它们也是有共性的。

• 凡是 web 目录，存放的都是web应用的入口脚本，一个 index.php 和一个测试版本的index-test.php

• 凡是 config 目录，存放的，都是本地配置信息 main-local.php 和 params-local.php

6.vendor vendor 。 这个目录从字面的意思看，就是各种第三方的程序。 这是Composer安装的其他程序的存放目录，包含Yii框架本身，也放在这个目录下面。 如果你向composer.json 目录增加了新的需要安装的程序，那么下次调用Composer的时候， 就会把新安装的目录也安装在这个 vendor 下面。

下面也是一些不太常用的文件夹7.vagrant 8.tests

入口文件篇：

1、入口文件路径：

http://127.0.0.1/yii2/advanced/frontend/web/index.php

每个应用都有一个入口脚本 web/index.PHP，这是整个应用中唯一可以访问的 PHP 脚本。一个应用处理请求的过程如下:

1.用户向入口脚本 web/index.php 发起请求。
2.入口脚本加载应用配置并创建一个应用实例去处理请求。
3.应用通过请求组件解析请求的路由。
4.应用创建一个控制器实例去处理请求。
5.控制器创建一个操作实例并针对操作执行过滤器。
6.如果任何一个过滤器返回失败，则操作退出。
7.如果所有过滤器都通过，操作将被执行。
8.操作会加载一个数据模型，或许是来自数据库。
9.操作会渲染一个视图，把数据模型提供给它。
10.渲染结果返回给响应组件。
11.响应组件发送渲染结果给用户浏览器

可以看到中间有模型-视图-控制器 ，即常说的MVC。入口脚本并不会处理请求，而是把请求交给了应用主体，在处理请求时，会用到控制器，如果用到数据库中的东西，就会去访问模型，如果处理请求完成，要返回给用户信息，则会在视图中回馈要返回给用户的内容。

2、为什么我们访问方法会出现url加密呢？

• < 上一篇

  PHP扩展开发检测清单

• 下一篇 >

  php的面试总结