Bug #36776

Property Mapping should be based on whitelist; configuration should be generated by form

Added by Sebastian Kurfuerst about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Should have
Category:
MVC
Start date:
2012-05-02
Due date:
% Done:

100%

Estimated time:
PHP Version:
Has patch:
No
Complexity:

Description

In order to make the property mapper more predictible and secure by default, we propose the following changes:

  • We should be able to explicitely map allowed fields, and ignore all non-specified fields.
  • If passing an object inside a link f.e., no modification of this object should be allowed at all
  • if using Fluid, it should be safe by default but not required to specify any property mapping configuration

Following are the changes needed:

Change PropertyMappingConfiguration
!!! BREAKING PropertyMappingConfiguration::shouldMap() should use WHITELIST instead of BLACKLIST

  • if a property is on blacklist, return FALSE directly
  • if a property is on whitelist, return TRUE
  • if all property are on whitelist, return TRUE
  • by default, return FALSE
  • $cfg->forProperty('image.author')->allowProperties('foo', 'bar')
  • $cfg->forProperty('image.author')->allowAllProperties()
  • $cfg->forProperty('image.author')->allowAllPropertiesExcept('foo')
  • Usually, you only use one of the following, not all of them!

PropertyMappingConfigurationBuilder should not set any type converter options by default

  • !!! BREAKING PropertyMappingConfigurationBuilder should NOT set any type converter options by default, especially not CONFIGURATION_CREATION_ALLOWED or CONFIGURATION_MODIFICATION_ALLOWED

generation of HMAC in Fluid Form Fields

!!! Fluid Form Fields should generate Property Mapping configuration of allowed fields appropriately
-> similar to v4 processRequest

Adjust ActionController

Action Controller: PropertyMapping config should be set from HMAC.

5) DOCUMENTATION:
wenn man nur bestimmte Objekte editieren soll (bspw. alle Blogs mit geradem erstellungsdatum) --> POLICY!!
--> values protected? (e.g. hidden fields / identity values that can't be changed)

#1

Updated by Gerrit Code Review about 9 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#2

Updated by Gerrit Code Review about 9 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#3

Updated by Gerrit Code Review about 9 years ago

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#4

Updated by Gerrit Code Review about 9 years ago

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#5

Updated by Gerrit Code Review about 9 years ago

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#6

Updated by Helmut Hummel about 9 years ago

This is something that needs to be changed in extbase as well, right? Is there already an accompanying ticket in the extbase tracker?

#7

Updated by Gerrit Code Review about 9 years ago

Patch set 6 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#8

Updated by Gerrit Code Review about 9 years ago

Patch set 7 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/10926

#9

Updated by Sebastian Kurfuerst about 9 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF