Reply to comment
Security of Views 2 when dealing with Drupal cache
I've been working with Views since Drupal 5.x, at that time it was the longest form you could ever have imagined. But it was still an awesome module with its ability to facilitate the creation of lists and tables to display content. With the release of Drupal 6.x, the community had to wait a while to get Views 2.0 in place. It came with great UI usability improvements, amazing enhancements and a brand new API.

One of the greatest parts of Views 2.0 is the Access Control, which offers the abiilty to restrict visibility access based on a role, a user, etc. If business logic is more complex than that the UI also allows one to configure, Views 2.0 to extended the system via custom access rules. The problem is that it has limitations when trying to deal with anonymous users. On certain circumstances Drupal core can store a views output into anonymous users cache, allowing untrusted users to access what is supposed to be restricted to them.
In order to solve the previous issue:
- Embed your view and allow your custom module handle its visibility and when its contents should be cached
- If it is shown in a specific path, turn off Drupal cache completely in the menu item definition
- Make sure to test your views with Drupal cache turned off & on before and after your adjustments
NOTE: Views has its internal cache. It is different to Drupal output cache, which is the HTML sent to browser.
Reply

develCuy's blog by Fernando Paredes Garcia is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Peru License.




