I've been wrestling a bit with how to create default views without exposing potentially sensitive data. What are others thinking about this issue?
The Views module includes support for "default" views implemented through a hook, hook_views_default_views(). A quick search through the contributions repository shows close to 60 modules implementing this hook.
Access to regular views can be limited through role-based restrictions, but default views do not include such restrictions (because there is no way to determine in advance what roles will exist on target sites). So default views have no access restrictions beyond the general 'access content' permission.
In many cases, the lack of access restrictions is not a problem, since regular node access restrictions apply. That is, a view will expose only nodes to which a user has view access.
However, module authors implementing views hooks are often associating additional data with nodes--data that may be sensitive and that may not typically be visible to users with view access to a node. Any time such data are included in a default view, there is the potential that sensitive data are being inadvertently exposed.
Module authors unaware of this issue easily could expose sensitive data. An example might be an accounting module tracking payments related to client work, where non-node payment records are attached to node project records. In this hypothetical example, a default view could expose payment data.
What to do about this issue?
Some ideas I've come up with are:
Possible advice to module developers:
- Don't create default views of potentially sensitive data
- If exposing default views, include instructions for overriding the views and restricting access by role.
Possible Views module approaches:
- Introduce option for default views to require overrides.
- Introduce permission-based access restrictions in addition to the existing role-based ones. This would enable a module to define its own permission, e.g., 'access accounting data', and restrict a view by this
permission.
Which of these options is best? Other ideas?
Comments
Views 2 has an answer
Er. Or it will. I haven't actually implemented this yet, but I've run into this exact problem. I want the access variable to optionally be a permission flag; I'm pretty sure I know how to set this up in Views 2 but I don't know if I can pull it off in Views 1 without breaking existing views.
Great!
Thanks Earl, sounds good.
Views 1
It's great that this will work in Views 2! Unfortunately, I need something for Views 1. I'm thinking of doing something along the lines of wrapping the default view code in the following:
if (user_access('module_permission')) {
}
This approach will need to be tweaked somewhat to allow it to be defined for admins, but it's a place to start at least.