If you can change the extension, then you can alter the way the server
handles the file, which is a security problem. So for example, you
can change a .JPG to a .PHP and then if you put some malicious PHP
code in the EXIF data, you can get the server to execute
it. Vulnerability is low because only users who have edit permissions
could do this.
Fixes ticket #846
* Remove the user_event callbacks and move them to the gallery_event callbacks. This will insure that the active user is always loaded (because the gallery callbacks are always called first) to its available to other gallery_ready handlers. Moved the method set_request_locale to the locales helper as it is more related to locales.
* Move the user controllers and views into the gallery module.
* Move the theme and block processing out of the user module and into core.
* Extend block_manager to handle sidebar blocks. get_available has become get_available_admin_blocks, get_list becomes get_admin_list.
* Create new functions get_available_site_blocks which will look for gallery_block get_available_site_blocks.
* Refactor sidebar_blocks into a separate function and then call block_manager::get_html(site.sidebar). Convert image_block to use block management instead of theme::sidebar_blocks
* Change the block_manager api so that the theme is passed into the get method. convert info to the new sidebar block approach
* Convert the user module to use the new sidebar block structure. remove the installers for info and image_block modules.
* Convert tag and rss modules to the new sidebar framework. reset the version number to 1 for info and image_block modules.
* Change the get_html method to ignore empty blocks and change the individual handlers to return an empty string if no block is generated
* Add a warning message if no sidebar blocks are active and provide a link to the admin page that configures the sidebar.
* moves the composite method back into core
* requires that the operation be fully qualified i.e. gallery_graphics::resize
* caches the graphics rules on each request
This is not currently necessary (nor is it a security hole) because we
don't constrain permissions at the child level in the core, but it
makes our security audits easier and will enable the scenario where
somebody writes a module to add per-photo permissions.
we're not relying on overriding url::site() to do tricks around item
urls. This means that you won't get item urls by doing
url::site("albums/37"), for example, but it also means that we won't
get pretty urls where we don't expect them (like in the action of a
<form> element).
Incidentally, this will help us move over to using the slug format
because if you've got a bad character in a url, the edit forms will
now work on it since they'll be id based.
2. Fix up an issue where we were crashing if there were no conflicting rows
3. Amend Item_Model so that if you change the slug, it flushes the cache
for all children
