Release notes
Issue #3032803 by Liam Morland: Fatal error: Cannot use [] for reading
Issue #2566547 by ljcarnieri, aoturoa: Fatal error when exposed filters is mandatory and not passed to the display view service
Fixing tests so they pass after changes have been made locally. Still havn't figured out why it doesn't work on D.O
Issue #2285055 by maxciceu, dnlt, kylebrowning, Bart Vanhoutte: PHP Timeout when accessing content type fields management
Issue #2905643 by nsk_ua: Multiple Notices services_views.resource.inc on line 254
Issue #2910966 by emerham, generalredneck, prakashsingh: php 7.1 Issues
Issue #2718537 by nico.knaepen, bessone, amoebanath, pcambra: Notice: Uninitialized string offset: 0 in services_views_execute_view()
Update services_views 7.x-1.3 (from 7.x-1.2)
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: /views/ output is different from / 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 'servicesclone$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.
services_views 7.x-1.4
Release notes Issue #3032803 by Liam Morland: Fatal error: Cannot use [] for reading Issue #2566547 by ljcarnieri, aoturoa: Fatal error when exposed filters is mandatory and not passed to the display view service Fixing tests so they pass after changes have been made locally. Still havn't figured out why it doesn't work on D.O Issue #2285055 by maxciceu, dnlt, kylebrowning, Bart Vanhoutte: PHP Timeout when accessing content type fields management Issue #2905643 by nsk_ua: Multiple Notices services_views.resource.inc on line 254 Issue #2910966 by emerham, generalredneck, prakashsingh: php 7.1 Issues Issue #2718537 by nico.knaepen, bessone, amoebanath, pcambra: Notice: Uninitialized string offset: 0 in services_views_execute_view()
Update services_views 7.x-1.3 (from 7.x-1.2)
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:/views/ output is different from / 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 'servicesclone$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.