I have started with the patch version of the zip file "moodle195-pages.zip" aquired on the http://moodle.org/mod/forum/discuss.php?d=93382, that you have published on it on Sunday, 19 July 2009, 01:28 AM. I had installed it on 1.9.5+ (Build: 20090624), and ended with the file uploaded to this issue named: moodle195-pages-SENT_TRACK-CONTRIB-1303-26Jan2010.zip Here are all the modifications I had made: /admin/roles/assign.php: - Used the 1.9.5 moodle version and changed as follows. - Added lines 290 - 310 in replacement of the commented if() that follows on line 311 (about this modifications, I already had commented on this issue, about it on 13/Jan/10 02:02 AM. I believe it could be much simplified, but I didn't managed to do so, because I couldn't create tests conditions to check the case CONTEXT_MODULE) /admin/roles/tabs.php: /admin/settings/top.php: - Those 2 files are the same of file "moodle195-pages.zip". /blocks/page/lang folder: - I added here the translations strings to PORTUGUESE. Please use it as more convenient. /blocks/page/block_page.php: - I had advanced, on line 6, the version from 20090301 to 20100101. Please adjust it as necessary to adopt the rules you follow to control this patch version. I changed it to better check on the server I used. - Added get_extra_capabilities() to Permit to Managers to control override of permission over the "Page Administration" Block in each page, for specific users or groups of users Here I question to you with the following doubth I have: Is there some permissions that shouldn't be here, for securities reasons? My intention was to make possible for Managers to transfer to specific users the management responsability of the "Page Adminsistration" block, in each page. Without this, managers don't have the possibility to do so. - Also added preferred_width() /blocks/page/index.php: - Corrected a small BUG, already reported on the http://moodle.org/mod/forum/discuss.php?d=93382#p614376 line 53: The variable $site was corrected to uppercase $SITE. /blocks/page/pagelib.php: - Added, on line 160 of blocks_move_position() function, one accessibility security check to prevent improper attempts execution by users that may try to manipulate the url to move blocks when editing mode is activated when view pages. I had noted that if users have block/page:update permission on the CONTEXT_PAGE (when viewing one page), he can move blocks even if they don't have 'moodle/site:manageblocks' permission. So I considered this as one security bug and Fix it here. About this, I also added some security checks on others files (See notes below concerning /lib/blocklib.php changes) /lib/accesslib.php: - On http://moodle.org/mod/forum/discuss.php?d=93382#p616877, I reported previous changes made on this file, as follows: FIX some missing of {$CFG->prefix} on : page line Existing code Possible correction needed ? 2386 INSERT INTO {context} INSERT INTO {$CFG->prefix}context 2388 FROM {page} p FROM {$CFG->prefix}page p 2390 FROM {context} cx FROM {$CFG->prefix}context cx 2447 FROM {context} FROM {$CFG->prefix}context - After many debugging tests to understand how to make it possible to managers to control the accessibility for each page, making it possible for example: - To some user get expanded access on specific pages to manage them and normal read-only access on others; So with the following code it became possible to manage overriding of permissions on each page. The changes I have made, to achieve this, was made on: - file \lib\accesslib.php, - on function fetch_context_capabilities(), as follows: case CONTEXT_PAGE: // course context and bellow // XXX - 25Jan2010 // The following lines was added by ermoodle to make possible // the permission overriding with the following extracaps ... // ... in each individual page, for specific users or groups of users // This way, it is possible to manager control who can manage each existing page $extracaps = array('moodle/block:view', 'block/page:create', 'block/page:delete', 'block/page:update', 'block/page:visibility', 'moodle/site:config', 'moodle/role:assign'); foreach ($extracaps as $key=>$value) { $extracaps[$key]= "'$value'"; } $extra = implode(',', $extracaps); $SQL = "SELECT * FROM {$CFG->prefix}capabilities WHERE contextlevel IN (".CONTEXT_BLOCK.",".CONTEXT_PAGE.") OR name IN ($extra)"; DOUBTH - moodle/site:config PERMISSION SHOULD BE HERE ? DOUBTH - moodle/role:assign PERMISSION Is useful to the managers to transfer the responsability of managing assing roles to specific pages, to specific users. /lib/blocklib.php: - I used the initial version of moodle 1.9.5 and changed it but Didn't changed the version number in order to make it easy to you to check it and adjust the version as convenient. - Line 463 till 479 Was added to FIX an security issue on blocks_execute_action(), as follows to avoid EXECUTION to users on the CONTEXT_BLOCK contexts that don't have moodle/site:manageblock but only have block/page:update capability (ON CONTEXT_PAGE Cases) ... if (($blockaction != 'config') && ($blockaction != 'add')){ // XXX - ermoodle Added next 3 lines - See above coments $block = blocks_get_record($instance->blockid); $cntxt = get_context_instance(CONTEXT_PAGE, $instance->blockid); if (!has_capability('moodle/site:manageblocks', $cntxt)){ error('Apparently you do not have the permission to manage and to '.$blockaction.' this block. Check it with the administrator.'); } } So, before the execution of config, moving (moveup, moveleft, ...), deleting, toogling or adding of blocks instances to the page view, this security check guarantees that the user in fact have the necessary permission of moodle/site:manageblocks on the CONTEXT_PAGE page. - This cuts the possibility for users to tring access pages in which they don't have moodle/site:manageblocks roles, by as example change the id=XX on the URL address of browsers: - EXAMPLE: users may change manually the id=2 to id=3, on http://YourMoodleSiteURL/blocks/page/view.php?id=2&instanceid=99&sesskey=SESSION_NUMBER&blockaction=movedown to TRY innaproperly MOVE (on this example, but it could try to delete, ...) the place of one block existing on the page id=3 Doing this kind of protection only on the blocks/page/pagelib.php (See above on /blocks/page/pagelib.php notes about it) override of this blocks_move_position(), protects only the "Page Administration" Block, but others loaded blocks on the CONTEXT_PAGE contexts will not be protected. SO, thats why I believe that this security patch is absolutly needed here ... /lib/pagelib.php: - I used the initial version of moodle 1.9.5 and changed it but Didn't changed the version number in order to make it easy to you to check it and adjust the version as convenient. - The changes on this file are related to the same situation reported on previous /lib/blocklib.php notes. So you will find that I had changed lines 564 till 578, with the following Security PATCH: // XXX - ADDED ON 20Jan2010 BY ER - OBJECTIVES - avoid access to moving blocks to // users on the CONTEXT_PAGE contexts that don't have moodle/site:manageblock // but only have block/page:update capability ... // - Doing this kind of protection only on the blocks/page/pagelib.php override of // this blocks_move_position(), protects only the "Page Administration" Block, // but others loaded blocks on the CONTEXT_PAGE contexts will not be protected. // - SO, thats why I believe that this patch is absolutly needed here ... if (has_capability('moodle/site:manageblocks', get_context_instance(CONTEXT_PAGE, $instance->blockid))){ DO THE ACTION, WHICH IN THIS CASE IS MOVING STUF .. } - I believe that it might be worthvalue to add this kind of security checks on others actions like adding, deleting, ... in order to avoid possible attempts for malware users to damage the look or do damages on the pages... Hoping that this helps to bug fix some existing bugs of this *Excellent* and *Great* block page, not only on the Moodle 1.95 version but also on future versions ...!