![]() |
|
Snippets |
|
if you won´t to add a foreignkey to sf_guard_user put this on top off you schema.yml file ;)
propel: _attributes : { package: "plugins.sfGuardPlugin.lib.model" } sf_guard_user: _attributes: { phpName: sfGuardUser } id:
now you can simple add a foreignkey
propel:
tbl_user_profile:
user_id: { type: integer, primaryKey: true, foreignTable: sf_guard_user, foreignReference: id, onDelete: cascade }
or
propel:
tbl_user_profile:
sf_guard_user_id:
With this snippet we can implement the following functionalities from the global configuration file config/config.php:
Access control to the applications in certain environments. For example, disable access in the environment of development from production server.
IP access control to certain applications of the project. For example, to protect backend or administration zones of the project.
To have several global configuration files of config/config.php according to the environment in which we are. For example, to define different constants for each environment.
I developed a mini-library (config/config.lib.php) to include and use in the global config file config/config.php.
<?php /** * IP access control to an environment * * @param string $env environment name * @param array $ips IPs that has access * @param string $clientip client IP */ function envCorrecte ($env,$ips,$clientip) { if (SF_ENVIRONMENT==$env) { $acces=0; foreach($ips as $ip) { $ipclient=substr($clientip,0,strlen($ip)); if ($ipclient==$ip) { $acces=1; } } if ($acces==0) { echo "Keep away! this is not a public environment."; exit; } } } /** * IP access control to an application of the symfony project * * @param array $apps no public applications * @param array $ips IPs that has access * @param string $clientip client IP */ function appCorrecte ($apps,$ips,$clientip) { // solve problem with key '0' in array $apps_aux[0]=''; $apps = $apps_aux + $apps; // if (array_search(SF_APP,$apps)!=false) { $acces=0; foreach($ips as $ip) { $ADR=$HTTP_SERVER_VARS['REMOTE_ADDR']; $ipclient=substr($clientip,0,strlen($ip)); if ($ipclient==$ip) { $acces=1; } } if ($acces==0) { echo "Keep away! ".SF_APP." is not a public application."; exit; } } } ?>
Finally config/config.php file can be like this:
<?php include("config.lib.php"); /** * IP access control to 'env' and 'int' environments */ $ip_dev=array("10.138.0.","192.168."); $ip_int=array("10.138.0.","192.168."); envCorrecte('env',$ip_env,$HTTP_SERVER_VARS['REMOTE_ADDR']); envCorrecte('int',$ip_int,$HTTP_SERVER_VARS['REMOTE_ADDR']); /** * IP access control to backend applications */ $ip_apps=array("10.138.0.","192.168.","w.x.y.z"); $apps=array('myapp_1','myapp_2','myapp_n'); appCorrecte($apps,$ip_apps,$HTTP_SERVER_VARS['REMOTE_ADDR']); /** * Custom config.php file for each environment */ include("config.".SF_ENVIRONMENT.".php"); /** * Common config.php file for all environments */ define("example","content1"); ?>
For some applications, the basic security layer offered by symfony is insufficient - often a database describes users organised into groups or hierarchical groups, and a way is needed to translate this into a symfony mechanism. Luckily this is quite easy: a filter can be implemented that redirects if the necessary auth criteria have not been met.
You will need to modify this to match your own objects, but it may be good to get you started. Place it in apps/frontend/lib/myDatabaseSecurityFilter.class.php:
<?php /** * Trying something to implement a database security layer * * HISTORY * 24 May 2006 - initial version */ class myDatabaseSecurityFilter extends sfBasicSecurityFilter { public function execute($filterChain) { // A call may be made up of several subcalls, so limit this to just the first one if ($this->isFirstCall()) { $context = $this->getContext(); $user = $context->getUser(); $strUser = $user->getUsername(); $strModule = $context->getModuleName(); $strRoute = $strModule . '/' . $context->getActionName(); // Only do security check if the module is security-enabled (which is default, so // use 'none' to turn it off $strParam = "mod_${strModule}_db_security"; $boolSec = sfConfig::get($strParam); if ($boolSec !== 'none') { // Get the UserMain object for this user $objUserMain = $user->getUserMain(); $objFuncs = $objUserMain->getUserFunctions($strRoute); // If the above checks did not OK this op, then refuse access if (count($objFuncs) < 1) { $fCtrllr = ''; if (!sfConfig::get('sf_no_script_name')) $fCtrllr = getenv('SCRIPT_NAME'); $context->getController()->redirect("$fCtrllr/default/notauth"); } } } $filterChain->execute(); } } ?>
Basically, this filter looks up a yaml config value on a per-module basis, called mod_<module>_db_security, and if it is set to 'none', then allows the filter to pass through. If it is not, it looks up the database user object (which for convenience I am keeping within my sfUser object) and performs a query called getUserFunctions(), which looks up the current module/action and determines whether this is allowed.
A redirect is called if no explicit authorisation is held, otherwise the module passes control to the next filter.
Then to install it, simply put:
myDbSecurityFilter:
class: myDatabaseSecurityFilter
in your apps/frontend/config/filters.yml file.
Let's say your site manages users who can create posts. You want to restrict the edition of a post to the administrator or the owner of the post. You would therefore like to have a security.yml file that looks like:
edit: is_secure:on credentials: [[administrator owner]]
but the problem is that the credentials are given to the user statically upon login.
The solution is therefore to give or take back credentials dynamically. As of now, the only way to achieve that is to “hijack” the getCredential action of the sfAction class.
Write the following in the action file of your post module:
// to put in the actions.class.php file function getCredential() { $this->post = $this->_retrievePost(); // retrieving the object based on the request parameters if ($this->getUser()->isOwnerOf($this->post)) $this->getUser()->addCredential('owner'); else $this->getUser()->removeCredential('owner'); // the hijack is over, let the normal flow continue: return parent::getCredential(); }
Of course you will have to write the sfUser::isOwnerOf function, which depends on your data structure. You will also have to write the _retrievePost function that returns null if no post have been found. Watch out for the isOwnerOf function: it has to return true if the post is new, otherwise users will never be able to create new posts.
Now the owner of a post can edit his post but not the others ones, except if he has administrator credentials. Everything is set up in the security.yml file. For example it is now trivial to add the same security check for the delete method.