smarty 学习笔记（2） 并周末计划

1. 今天把昨天遇见的问题解决掉了，完成了如何在smarty的模板里加载php文件。

{include-php file = "load_tickte.php"}

当需要加载的是变量模块时，只需要把上代码修改成：

{include-php file = "$modTpl"}


2. 今天重复了一个以前就遇见的问题，prototype使用的时候调用$F('ID')的方法时，调用的是DOM的getElementById() 方法 ，如果标签中的id和name相同，则会在firefox引起问题，所以需要在标签里定义不同的name和id，id需要保证其唯一性。这样就可以保证在firefox的兼容。


3.在使用firefox 的时候，在里定义了charset，但是还是显示的是乱码（ISO-8859-1）。在调用php的时候，强制加了一个header的头部,如下:

header('Content-Type:text/html; charset=utf-8')

这样就能强制浏览器输出utf-8 ，我们的客户中心也是如此完成的。

1. 找了一些关于header的资料。可以看看，原来html的header的作用还是很大的。


2. 明天想重新完善下ci的权限模块，到现在都没整理好一个完整的，良好的权限模块构想，明天需要参考下discuz和我们的后台，看看权限是怎么部署的。

3. 看看prototype的使用，想使用下prototype的高级功能，并看下其他的ajax框架。

4. 有时间还是要玩玩linux和python，玩熟了在研究java。

smarty 模板引擎解析

php的smarty的解析引擎，明天的重点需要研究，到底怎么在模板里加载动态的页面和动态的模板-----------功能模块。

php smarty 学习笔记（1）

1.

这个周末很无聊。就开始了改造原来做的客户情报中心的工作，想来想去，现在的页面越看越烦，所以决定使用Smarty的模板。

2. 安装smarty模板引擎

以前就用过Smarty的模板，但是看网络上介绍的配置方式很是麻烦。最后自己研究了一下，才发现了一些问题。smarty安装以后，如果是简单的使用，只需要拷贝libs目录到smarty根目录下面即可。

然后再进行配置配置文件，smarty需要配置4个目录，见下配置文件目录
include('smarty/Smarty.class.php');
$smarty = new Smarty;
$smarty->template_dir = "templates/";
$smarty->compile_dir = "smarty_templates_c/";
$smarty->config_dir = "configs/";
$smarty->cache_dir = "smarty_cache/";
?>

有些人说，定义文件需要使用绝对路径，但使用绝对路径扩展性就不强，每次配置就需要重新配置一次smarty模板引擎。


smarty_templates_c/存放的是smarty的模板目录的缓存，templates存放的是smarty文件的模板目录地址，configs是smarty的配置文件（现在我只存放着config.php）。

下图就是现在准备修改的目录结构图。


只需要按照配置就可以立即配置起smarty的php引擎。


3. 今天遇见的错误

在$smarty->display("模板") ，现实加载模板之前，需要先定义所有的变量，如果是先加载现实模板，再定义变量，则会显示错误。

-----------看来一些不起眼的错误，会对效率有严重的影响，但是对问题的解决也是最佳的学习过程。


4. 工具

看见有人在使用xplorer2。感觉不错，明天去公司也安装上，免得总是出现开无数个窗口，自己都不知道干什么的情况。


睡觉咯~~~~

Kerberos简介

Kerberos协议：

Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO(Single Sign On)。由于在每个Client和Service之间建立了共享密钥，使得该协议具有相当的安全性。

条件

先来看看Kerberos协议的前提条件：

如下图所示，Client与KDC， KDC与Service 在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部， 使其应用场景不同于X.509 PKI。

过程

Kerberos协议分为两个部分：

1 . Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。

此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。

（此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式）

2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别。

Kerberos协议的重点在于第二部分，简介如下：

1． Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。

2． 此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。

3． 为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。

4． Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。

5． 如果Service有返回结果，将其返回给Client。

总结

概括起来说Kerberos协议主要做了两件事

1． Ticket的安全传递。

2． Session Key的安全发布。

再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。

附加： kerberos的原理