Install

Works with Drupal: 7.x

Using Composer to manage Drupal site dependencies

Downloads

Download services_views-7.x-1.3.tar.gztar.gz 20.82 KB
MD5: 5a15ee959e6aa69e943527432168b916
SHA-1: 2fb129d28b7cf5ded32363f47d201c41fcc3be80
SHA-256: b3064bfc140e6bde90f99aa4228299fc25f135fc48ebead5f6bc4a468b09a914
Download services_views-7.x-1.3.zipzip 26.59 KB
MD5: 8f5918a016ea4e5c7ff36167e1c57b32
SHA-1: 5b20916e18e6ff0fd86389fabc202fb785304a0d
SHA-256: 85681fd5fda22e5b951ed8974904c982d6798a3bccc529a9fbdf228496668aad

Release notes

It is highly recommended to not preform this upgrade on a production environment first.
It is highly advised to upgrade to 7.x-1.2 before upgrading to 7.x-1.3,

This release is purposefully difficult to upgrade to. It forces more secure practices!

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 run UPDATE 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.

Created by: generalredneck
Created on: 1 Dec 2017 at 15:10 UTC
Last updated: 14 Nov 2019 at 16:03 UTC
Bug fixes
New features

Other releases