Xem mẫu

Chapter 11 Replacing We can use preg_replace() to replace patterns with alternative text. This is often used for stripping out unwanted data. In this example we remove all digits. $value = preg_replace(`/\d/`, ``, $value); The first parameter is the pattern, in this instance, digits. The second parameter is the replacement string, in this instance, a null string. The final parameter is the subject. We can take advantage of blocks in the same way as we did with preg_match(). Each matched block encapsulated in parentheses is assigned to a variable $1 through $n. These variables are only accessible in the replacement parameter. $pattern = `/^(\d{4})\D(\d{1,2})\D(\d{1,2})$/`; $replacement = `$1/$2/$3`; $value = `1791-12-26`; echo preg_replace($pattern,$replacement,$value); This example will output: 1791/12/26 Access Control Joomla!`s access control mechanisms are not as clear cut as they could be; this is due to an ongoing development cycle that is moving away from a legacy access control system. In the future, Joomla! will use a complete GACL (Group Access Control Lists) access control mechanism. The current access control mechanism uses an incomplete, abstracted implementation of phpGACL. There are eleven user groups; these groups are sometimes referred to as usertypes. Joomla! also maintains a set of three legacy access groups, Public, Registered, and Special. The legacy groups are stored in the #__groups table; theoretically this makes the legacy access groups dynamic. There is no mechanism for administrators to amend the legacy access groups and even if we manually add a new legacy access group to the #__groups table, the effects are not globally reflected; we should regard the legacy access groups as static. It is advisable not to make extensions dependent on the legacy access groups because they will probably be removed from Joomla! at a later date. We should be most interested in the phpGACL groups (simply called groups or user groups). Currently no mechanism is provided for administrators to amend these groups, we can, however, take advantage of the powerful JAuthorization [ 323 ] Error Handling and Security class that extends the gacl_api class. If we are careful we can add groups to Joomla! without impacting the Joomla! core. In the GACL implementation we commonly use four terms: Name ACL Access Control List ACO Access Control Object AXO Access eXtension Object ARO Access Request Object Description Permissions list for an object Object to deny or allow access to Extended object to deny or allow access to Object requesting access For a more complete description of GACL refer to the official phpGACL documentation phpgacl.sourceforge.net. To demonstrate how the user groups are initially defined, this screenshot depicts the phpGACL administration interface with the Joomla! user groups defined: Note that Joomla! does not include the phpGACL administration interface and that this screenshot is intended for demonstration purposes only. In phpGACL, permissions are given to ARO groups and AROs, to access ACOs and AXOs. In Joomla! we only give permissions to ARO groups, and Joomla! users can only be a member of one group, whereas in phpGACL AROs can be members of multiple groups [ 324 ] Chapter 11 These differences between Joomla! and phpGACL are due to one major factor. In phpGACL when we check permissions, we ask the question `does ARO X have access to ACO Y?` In Joomla! we ask the question, `Does ARO group X have access to ACO Y?`. The way in which we assign permissions in Joomla! will be altered in the future to use the same principals as phpGACL. The three Access Object types, ACO, AXO, and ARO are all identified using two values, section and section value. To put this into context, the user group (ARO group) Super Administrator is identified as users>superadministrator. The section name is users, and the section value is superadministrator. A permission to manage contacts in the core contact component (ACO) is expressed as com_ contact>manage. The section name is com_contact, and the section value is manage. Menu Item Access Control A misconception among some Joomla! administrators is that menu access (which uses the legacy access groups) constitutes security. Menu access is intended to define whether or not a specific menu item should be made visible to the current user. Joomla! always attempts to transfer menu item permissions to the related menu item content; however, the solution is not infallible and must not be relied upon. The best way to deal with this is to add support for permissions in our extensions. The next section describes how to do this. We should also try to make administrators aware of the true meaning of the menu item access level. In cases where Joomla! determines that something should not be accessible to a user, because of menu item access, Joomla! will return a 403 (Access Denied) error code. Extension Access Control Imagine we have a component called myExtension and we want to grant super administrator`s access to `manage`. This example gives permission to ARO group users>superadministrator to ACO com_myExtension>manage. $acl =& JFactory::getACL(); $acl->_mos_add_acl(`com_myExtension`, `manage`, `users`, `super administrator`); Whenever we want to add permissions we have to use the above mechanism because currently only these ARO tables are implemented in Joomla!. The absent ARO tables are scheduled to be implemented in a later version of Joomla!. [ 325 ] Error Handling and Security In the short-term, when we create extensions that use Joomla!`s implementation of permissions, we should create a separate file with all the necessary calls to the ACL _mos_add_acl() method (as demonstrated in the preceding example). This way when Joomla! ultimately supports the ARO tables, we will be able to easily refactor our code to incorporate the new implementation. Calls to the _mos_add_acl() method must always be made prior to any permission checks. If they are not, the extra permissions will not have been applied in time. The best place to add the permissions is in the root extension file (this will depend upon the extension type). Once we have added all of our permissions we will probably want to check if the current user has permissions. There are various ways of achieving this; we are encouraged to use the authorize() method in the JUser class: $user =& JFactory->getUser(); if( ! $user-> authorize(`com_myExtension`, `manage`) ) { JError::raiseError(403, JText::_(`Access Forbidden`)); } If we are developing a component using the MVC architecture we use the JController object to automatically check permissions. The example below creates the component controller, sets the controller`s ACO section, and executes the task: $task = JRequest->getVar(`task`, `view`, `GET`, `WORD`); $controller = new myExtensionController(); $controller->setAccessControl(`com_myExtension`); $controller->execute($task); When we run execute(), if the controller knows which ACO section to look at, it will check the permissions of the current user`s group. The example above checks for permissions to ACO com_myExtension>$task. We don`t have to use the task as the section value; instead we can use the optional second parameter in the setAccessControl() method. This example checks for permissions to the ACO com_myExtension>manage irrespective of the task: $task = JRequest->getVar(`task`, `view`, `GET`, `WORD`); $controller = new myExtensionController(); $controller->setAccessControl(`com_myExtension`, `manage`); $controller->execute($task); [ 326 ] Chapter 11 When dealing with more complex permissions we can use AXOs to extend ACOs. Let`s imagine we have a number of categories in our extension and we want to set manage permissions on each category. This example grants permissions to ACO group users>superadministrator to ACO com_myExtension>manage AXO category>somecategory: $acl =& JFactory::getACL(); $acl->_mos_add_acl(`com_myExtension`, `manage`, `users`, `super administrator`, `category`, `some category`); Unlike when we were dealing with just an ACO and ARO, we cannot use this in conjunction with a JController subclass. This is because the JController class is unable to deal with AXOs. Instead we should use the JUser object to check permissions: $user =& JFactory->getUser(); if( ! $user-> authorize(`com_myExtension`, `manage`, `category`, `some category`) ) { JError::raiseError(`403`, JText::_(`Access Forbidden`)); } When you define your ACOs you should always use the name of your extension as the ACO section. How you choose to define your ACO section value and your AXOs is entirely up to you. There is a great deal of emphasis put on the flexibility of Joomla!. As a third-party developer, you do not have to use the normal Joomla! access control. If you choose to use a custom access control system and the Joomla! MVC, you may want to consider overriding the authorize() method in your JController subclasses. Attacks Whether or not we like to think about it, there is always the potential threat of an attacker gaining access to our Joomla! websites. The most common way in which security is breached in Joomla! is through third-party extension security flaws. Due to the number of extensions that have security defects, there is an official list of extensions that are considered insecure, available in the FAQ sections at http://help.joomla.org. It is very important that, as third-party extension developers, we take great care in making our extensions as secure as we can. In this section we will investigate some of the more common forms of attack and how we can prevent them from affecting our extensions and we will take a look at how we can deal with users whom we believe to be attackers. [ 327 ] ... - tailieumienphi.vn
nguon tai.lieu . vn