Install
Works with Drupal: 7.xUsing Composer to manage Drupal site dependencies
Downloads
Release notes
This is a re-release of 1.3-RC1. After little involvement from the security team after the initial launch, I decided to go ahead and release this as a normal release to remove the blocker of getting the issue queue under control.
Follow up on SA-CONTRIB-2017-062: Arbitrary Views exposed over API
Implementation of #2900460: Make the Views Resource enforce better security practices..
This release is the Release Candidate version for the final fix for SA-CONTRIB_2017-062.
The Problem
The reason this security issue is a problem is because by default, panel pane displays, block displays, and several other type of displays, are not accessible via a "route" by default and would not be accessible to the public unless someone put them on a page that was accessible to the public.
The Solution
The previous workaround allows you to designate specific displays that are are available via the views resource. See more in the 7.x-1.2 Release Notes. The module now takes the configuration you did there, and creates "Services" type views. Starting with this release, "Services" type views will be the only accessible view display type using the views resource.
Given this solution, whitelisting and blacklisting among the existing and newly cloned services displays will be maintained for now. This allows you to limit access to a highly sensitive services view on one endpoint, while opening it up on another.
Only one clone of each accessible view display will be created. This means that if you have the same view accessible via 3 endpoints, all 3 endpoints will share the same new clone. Additionally, only whitelisted view displays attached to endpoints that are enabled and view resource is enabled will be considered for cloning.
Also if you wish to change to the Services Views Resources, you can. The default path for the newly created displays will be $ENDPOINT/$VIEW_NAME/$DISPLAY_NAME. Keep in mind though #1647360: <endpoint>/views/<view_name> output is different from <endpoint path>/<resource name> for the same view.
Backward Compatibility
If you set up configuration to limit the view displays that can be accessed using the view resource, then a copy of those displays with the format 'services_clone_$old_display_name' will be created. Services Views relies on this naming convention to be able to check to see if the display name you are trying to access using the API has a new services clone. Please do not change this unless you are willing to break the backward compatibility.
FAQ
- When I access http://mysite.com/api_endpoint/views/view_machine_name.json?display_id=d..., I'm now getting a 404. What happened to my view service?
- This was a security feature implemented and described above. Basically, if you didn't set the settings necessary to secure your site,
the module has forced it upon you. You have most likely encounted one of FAQs below. If you have performed this upgrade on production,
the easiest solution is to downgrade back to 7.x-1.2 and runUPDATE system SET schema_version = 0 WHERE name = 'services_views';
. Then follow the steps listed in the 7.x-1.2 Release Notes and white list the displays you wish to remain available in 7.x-1.3. - Why do I get the following message? "Cowardly refusing to make a clone of all view displays."
- This means that you have left the whitelisting configuration for an endpoint at it's default of everything being available. If all displays need to be cloned, restore to the latest backup, and update your settings by whitelisting them all (not blacklisting none) and try again.
- I didn't upgrade to 1.2 when the security release came out. So can I upgrade from Services Views <= 1.1 straight to 1.3?
- So if you do, you will automatically get the message in the question before this. Never fear though... you didn't upgrade this module directly on production right? If you did, see the first question.
Otherwise, take a gander at #2900460-14: Make the Views Resource enforce better security practices.. An explanation on how to programmatically achieve an upgrade directly to 1.3 is described there.