fr [1] => fr_FR [2] => en_US [3] => en )
ISO-8859-1 [1] => UTF-8 [2] => * )
内容类型数组
sfActions类提供了一些代理来快速地访问请求方法
getRequest()->hasParameter('foo');
$hasFoo = $this->hasRequestParameter('foo'); // Shorter version
$foo = $this->getRequest()->getParameter('foo');
$foo = $this->getRequestParameter('foo'); // Shorter version
}
}
对于文件上传的请求，sfWebRequest对象提供了访问和移动这些文件的手段：
getRequest()->hasFiles())
{
foreach ($this->getRequest()->getFileNames() as $fileName)
{
$fileSize = $this->getRequest()->getFileSize($fileName);
$fileType = $this->getRequest()->getFileType($fileName);
$fileError = $this->getRequest()->hasFileError($fileName);
$uploadDir = sfConfig::get('sf_upload_dir');
$this->getRequest()->moveFile('file',$uploadDir.'/'.$fileName);
}
}
}
}
用户Session
Symfony自动管理用户Session并且能在请求之间为用户保留持久数据。他使用PHP内置的Session处理机制并提升了此机制，这使得symfony的用户Session更好配置更容易使用。
访问用户Session
当前用户的Session对象在动作中使用getUser()方法访问，他是sfUser类的一个实例。sfUser类包含了允许存储任何用户属性的参数仓库。用户属性能够存放任何类型的数据（字符串、数组、关联数组等）。
sfUser对象能够跨请求地保存用户属性
getRequestParameter('nickname');
// Store data in the user session
$this->getUser()->setAttribute('nickname',$nickname);
}
public function executeSecondPage()
{
// Retrieve data from the user session with a default value
$nickname = $this->getUser()->getAttribute('nickname','Anonymous Coward');
}
}
可以把对象存放在用户Session中，但这往往让人气馁，因为Session在请求之间被序列化了并且存储在文件中，当Session序列化时，存储对象的类必须已经被加载，而这很难被保证。另外，如果你存储了Propel对象，他们可能是“延迟”的对象。
与symfony中的getter方法一样，getAttribute()方法接受第二个参数作为默认值（如果属性没有被定义时）使用。判断属性是否被定义使用hasAttribute()方法。属性存储在参数仓库可使用getAttributeHolder()方法访问，可以使用基本参数仓库方法很简单的清除用户属性：
getUser()->getAttributeHolder()->remove('nickname');
}
public function executeCleanup()
{
$this->getUser()->getAttributeHolder()->clear();
}
}
用户Session属性在模板中默认通过$sf_user变量访问，他存储了当前的sfUser对象
PHP;">
Hello,getAttribute('nickname') ?>
如果只想在当前请求中存储信息，你更应该使用sfRequest类，他也有getAttribute()和setAttribute()方法，只有在请求之间持久存储信息时才适合sfUser对象。
Flash属性
Flash属性是一种短命属性，他会在最近的一次请求后消失，这样可以保持你的Session清洁
setFlash('attrib',$value);
在另一个动作中获取Flash属性：
getFlash('attrib');
一旦传入了另一个动作，Flash属性就消失了，即使你的Session还不过期。在模板中访问flash属性使用$sf_flash对象。
PHP;">
has('attrib')): ?>
get('attrib') ?>
或者
PHP;">
get('attrib') ?>
Session管理
Symfony的Session处理特性对开发者完全掩盖了客户端与服务端的SessionID存储，当然，如果你非要去改Session管理机制的默认行为也不是不可能，高级用户经常这么干。
客户端，Session被Cookies处理（handle）。Symfony的Session Cookie叫做symfony，可以在factories.yml中修改。
自定义Cookie名字
Symfony的Session基于PHP的Session设置，也就是说如果希望客户端使用URL参数方式取代Cookies，你必须修改PHP.ini文件的use_trans_sid参数，不建议这么做。
在服务器端，symfony默认使用文件存储用户Session，可以通过修改factories.yml文件承担class参数来使用数据库存储：apps/myapp/config/factories.yml
MysqLSessionStorage
param:
db_table: SESSION_TABLE_NAME # 存储Session的表
database: DATABASE_CONNECTION #
数据库的
名称
Class
名称可以是：f
MysqLSessionStorage,sfPostgre
sqlSessionStorage和sfPDOSessionStorage；后面是首选方式。
Session超时的
修改和调整：apps/myapp/config/settings.yml
default:
.settings:
timeout: 1800 #Session超时 单位秒
动作的安全
动作的执行可以被限定在具有一定权限的用户。Symfony为此提供的工作允许创建安全的应用，用户只有在通过认证之后才能防伪应用的某些特性或部分。设置安全的应用需要两步：定义动作需要的安全和使用具有权限的用户登录。
访问限制
在每个动作执行前都会被一个特定的过滤器来检查当前用户是否具有访问的权限，symfony中权限有两个部分组成：
① 安全动作只有被授权用户可以访问
② 凭证允许分组管理权限
通过创建或者修改config目录下的security.yml文件即可简单的完成安全访问限制。在文件中可以设置某个动作或者所有动作是否需要授权。
Apps/myapp/modules/mymodule/config/security.yml
用户都可以请求Read动作
update:
is_secure: on # update动作只能有认证的
用户访问
delete:
is_secure: on # 同update
credentials: admin # 具有admin凭证
all:
is_secure: off # 无需授权
用户访问一个需要授权的动作将依据用户的权限：
① 用户已登录并且凭证符合则动作能执行
② 如果用户没有登录则转向默认登录动作
③ 如果用户已登录但凭证不符合则会转向默认的安全动作
转向将根据apps/myapp/config/settings.yml文件来决定
授权
为某用户授权：
getRequestParameter('login') == 'foobar') //判断根据具体需求而定
{
$this->getUser()->setAuthenticated(true); //设置
用户为已认证
}
}
public function execute
logout()
{
$this->getUser()->setAuthenticated(false); //设置
用户为未认证
}
}
在动作中处理凭证：
403@getUser();
//
添加凭证
$user->addCredential('foo');
$user->addCredentials('foo','admin'); //
添加多个凭证
// 判断是否具有凭证
echo $user->hasCredential('foo'); => true
// 判断是否具有多个凭证
echo $user->hasCredential(array('foo','admin')); => true
// Check if the user has one of the credentials
echo $user->hasCredential(array('foo','admin'),false); => true
//
删除凭证
$user->removeCredential('foo');
echo $user->hasCredential('foo'); => false
//
删除所有凭证 (被用在注销处理过程中)
$user->clearCredentials();
echo $user->hasCredential('admin'); => false
}
}
如果用户具有'admin'凭证，他就可以访问security.yml文件中设定只有admin可以访问的动作。凭证也经常用来在模板中显示授权信息
PHP;">
hasCredential('section3')): ?>
sfGuardPlugin插件扩展了session类，使得登录与注销的处理变得简单。
复杂的凭证
在security.yml文件中，可以使用AND或者OR来组合各种凭证，这样就可以建立复杂的业务流和用户权限管理系统。例如，CMS系统后台办公自由具有admin凭证用户访问，文章的编辑必须有editor凭证，发布只能有有publisher凭证的用户，代码如下：
PHP;">
editArticle:
credentials: [ admin,editor ] # admin 和 editor
publishArticle:
credentials: [ admin,publisher ] # admin 和 publisher
userManagement:
credentials: [[ admin,superuser ]] # admin 或者 superuser
每次添加新的[]，凭证之间的关系在AND和OR之间切换，这样可以创建及其复杂的凭证组合关系：
PHP;">
credentials: [[root,[supplier,[owner,quasiowner]],accounts]]
# root 或者 (supplier 和 (owner 或者 quasiowner)) 或者 accounts
注：【和】所有凭证都满足，【或】满足其中的一个凭证。
验证输入是重复且单调的事情，symfony提供了内置的请求验证系统，使用动作类的方法。
看个例子，当一个用户请求myAction，symfony首先去查找validateMyAction()方法，如果找到了就执行，根据返回结果来决定如何往下走：如果返回真则executeMyAction()被执行，否则handleErrorMyAction()被执行，并且，如果找不到handleErrorMyAction，symfony则去查找普通handleError方法，如果还不存在则简单返回sfView::ERROR并递交myActionError.PHP模板，看下图：
说明：
① validateActionName是验证方法，是ActionName被请求的第一个查找方法，如果不存在则直接执行动作方法。
② handleErrorActionName方法，如果验证失败则查找此方法，如果不存在则Error模板被显示
③ executeActionName是动作方法，对于动作他必须存在。
看段代码：
getRequestParameter('id') > 0);
}
public function handleErrorMyAction()
{
$this->message = "Invalid parameters";
return sfView::SUCCESS;
}
public function executeMyAction()
{
$this->message = "The parameters are correct";
}
}
可以在验证方法中加入任何代码，但最终只要返回true或者false即可。因为是sfActions类的方法，所以可以访问sfRequest和sfUser对象，这样将对于输入与上下文验证非常有利。
过滤器
安全处理可以被认为是请求到动作执行之前必须经过的一个过滤器。实际上可以在动作执行前(后)设置任意多个的过滤器。
过滤器链
Symfony实际上将请求处理看作是过滤器链。框架收到请求后第一个过滤器（通常是sfRenderingFilter）被执行，在某些时候他调用下一个过滤器，依次下去。当最后一个过滤器（通常是sfExecutionFilter）执行后，前一个过滤器结束，依次返回去知道rending过滤器。
所有的过滤器均继承自sfFilter类并且都包含了execute()方法，此方法之前的代码在动作（action）之前执行，此方法之后的代码在动作之后执行，看一段代码（下一节中要用到，取名myFilter代码）：
execute();
// 在动作之
后执行的
代码
...
}
}
过滤器链在/myapp/config/filters.yml文件中定义：
这些声明都没有参数（~在symfony中的意思是null，将采用默认的值），他们都继承自symfony核心定义的参数，symfony为每一个过滤器（除了自定义过滤器）定义了类和参数，他们在$sf_symfony_data_dir/config/filter.yml文件。
① 设置过滤器的enabled参数为off将禁用过滤器，例如：
你还可以通过settings.yml文件达到此目的，修改web_deug、use_security、cache和use_flash的设置即可，应为每一个默认过滤器都有一个condition参数来自上面的配置。
② 不要通过删除filters.yml文件中的过滤器来禁用该过滤器，symfony将抛出异常
③ 可以自定义过滤器，但无论如何rendering必须是第一个，而execution必须是最后一个
④ 为默认过滤器重写默认类和参数（特别是修改security系统和用户的安全验证过滤器）
通过创建myFilter的类可以非常简单的常见自定义的过滤器，把类文件放在项目的lib文件夹可以充分利用symfony提供的自动加载特性。
由于动作之间可以互相跳转，因此过滤器链会在每一个请求中循序执行。但更多的时候可能需要是第一次请求的时候执行自定义的过滤器，这时候使用sfFilter类的isFirstCall()方法。看下面代码：apps/myapp/lib/rememberFilter.class.PHP（例子）
isFirstCall())
{
// 过滤器不直接访问请求和
用户对象，你需要使用context对象
获取
// You will need to use the context object to get them
$request = $this->getContext()->getRequest();
$user = $this->getContext()->getUser();
if ($request->getCookie('MyWebSite'))
{
// 登入
$user->setAuthenticated(true);
}
}
// 执行下一个过滤器
$filterChain->execute();
}
}
有时候需要在一个过滤器执行之后跳往另一个动作而不是下一个过滤器。sfFilter不包含forward方法，但sfController包含，使用下面的语句：
getContext()->getController()->forward('mymodule','myAction');
sfFilter类有一个initialize方法，在对象创建的时候执行，可以在自定义的过滤器中覆盖此方法以达到更加灵活地设置参数的目的。
过滤器激活及参数
过滤器创建后还必须进行激活，在apps/myapp/config/filters.yml文件中：
自定义过滤器中的参数可以在过滤器代码中使用getParameter方法获取：
apps/myapp/lib/rememberFilter.class.PHP
getCookie($this->getParameter('cookie_name')))
...
}
}
Condition参数被过滤器链测试来决定是否必须被执行。因此自定义过滤器声明能够依赖一个应用配置。要是过滤器执行，记得在应用的app.yml中加入：
过滤器示例
如果想在项目中包含特定的代码，你可以通过过滤器实现（layout方式需要在每一个应用中都要设置），看下面的代码：
execute();
// 使用下面的
代码修饰响应
$googleCode = '
';
$response = $this->getContext()->getResponse();
$response->setContent(str_ireplace('
