Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 300626

\Drupal\rest\Plugin\rest\resource\EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior

$
0
0

Discovered by Berdir at #2789315-52: Create EntityPublishedInterface and use for Node and Comment and subsequent comments.


berdir> WimLeers: $entityKeys and $translatableEntityKeys are the values of those entity keys for fast access.
11:31:51 <WimLeers> berdir: so is it just for fast access then?
11:32:03 <berdir> WimLeers: there isn't really any documentation what they are. They basically have only one purpose: To allow generic access to a common concept without harcoding a field/property name
11:32:18 <WimLeers> berdir: ughhhh
11:32:32 <WimLeers> berdir: but this basically means \Drupal\rest\Plugin\rest\resource\EntityResource::patch is incorrect
11:33:25 <berdir> So if anything then rest should not do that logic for all entity keys. either it should do it for *all* fields (sending a value without changing it does not require write permission. but could this could allow you to figure out the value of a field you are not allowed to see or change. just try until you don't get an error) or only specific, actually read-only keys like id and bundle
11:34:02 <berdir> WimLeers: well. if it makes you fell better, it is not alone. entity storage makes a similar wrong assumption and makes fields that have an entity key pointing to them required/NOT NULL in the schema
11:34:30 <WimLeers> berdir: right, I remember researching this in depth and seeing it somewhere
11:34:40 <WimLeers> berdir: that's also why nobody noticed it while working on that patch
11:34:51 <WimLeers> berdir: it's interesting how REST unveils more flaws in Entity API
11:35:00 <WimLeers> berdir: because form-based assumptions are no longer present
11:35:18 <WimLeers> berdir++
11:35:22 <berdir> WimLeers: I think a better thing to do would be to respect the read-only property of the field definitions, see \Drupal\Core\Entity\ContentEntityBase::baseFieldDefinitions()
11:35:41 <berdir> WimLeers: which nothing in core actually uses yet
11:36:27 <berdir> WimLeers: what is interesting there though is that revision_id is also marked as read only. but the API actually allows you to save a new revision with a specific revision id, but that's basically just for migrate, nobody else should rely on that :)
11:36:37 <berdir> and it seems like a sane assumption to not allow that over rest
11:36:50 <WimLeers> berdir: but that's the thing, we dont' really want to whitelist every read-only thing. We just want the critical things to be sent. Nothing more. Although this would actually be even better, from the "be liberal in what you accept, be conservative in what you send" principle (https://en.wikipedia.org/wiki/Robustness_principle)
11:37:00 <WimLeers> berdir: oh heh
11:37:04 <WimLeers> berdir: yes please no :D
11:37:13 <WimLeers> berdir: but then how can we automatically detect that?
11:38:05 <berdir> WimLeers: I think we should at least try what happens if we switch that logic to checking the read only property instead. this makes much more sense to me than the current entity key based code. can you open an issue? :)
11:38:08 <WimLeers> +1

Viewing all articles
Browse latest Browse all 300626

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>