When using both a "live"/build server and a preview server,
and the option "Only trigger builds for published content" is EITHER checked or not,
and the user saving the content has permission to see draft content,
and there is related content that has an unpublished default revision (ie, never before published),
the unpublished related content is posted to the live/build server.
For our purposes we are using nodes and storage entities, and content moderation is enabled for both.
Install "storage" module, or use another entity type.
Create a storage type.
Create a content type with an entity reference field to the storage type.
Enable content moderation workflows for both.
Create a storage entity and save it as a draft/unpublished.
Create a node and relate the storage entity to it.
Publish the node, but do not publish the storage entity.
Observe: JSON stored in fastbuild log is based on content editor's permissions, and includes unpublished related storage entities.
When the API user requests the fastbuilds endpoint, that user's permissions are not validated and it is served the stored json, regardless of what it should have access to.
I'm not sure what the best resolution is here, in the module itself. I have created a workaround for it, by using a RouteSubscriber to override the GatsbyFastbuildsController, and I have attached that override here. You can see I'm re-adding the json when the API user requests the data, so that user's permissions are taken into account.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3347297-5.patch | 18.75 KB | apmsooner |
| GatsbyFastbuildsOverride.txt | 2.42 KB | lisagodare |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
mmafe commentedWe are also experiencing this issue.
In our case, we're not using storage entities. We are using content moderation with node entities.
Randomly, pages that are unpublished are leaking onto the live/build server.
Hoping there's going to be a resolution quickly for this one as our users can no longer rely on an "unpublished" page being unpublished.
Comment #5
apmsooner commentedI don't know if this solves your exact issue or not and it's difficult to test locally without having a separate preview/build server but this patch syncs up the logging service with the hooks, factors in the build_published option to early return for non-node entities when its true, and accounts for entities like "redirects" that don't have a publish state to also be triggered. It "should" resolve draft versions getting on build server. @lisagodare, your description involving referenced entities also in a moderated state may be a more unique issue and seemingly to me a case where those references might be better served as entity_reference_revisions if you're still having issues beyond this patch.
Comment #6
apmsooner commentedNoting here also... per Shane & Tyler at Gatsby, the version 2 of the module depends on fast_builds being enabled and thus it never sends json to the gatsby site like version 1 did. It just creates the log entity and triggers the gatsby site to make a request to the api endpoint to retrieve the data. So i've removed the json variables from the functions and the json logging setting should really just go away as its irrelevant since the data exists in the logging entity itself. One other important note, the "Only trigger builds for published content" is confusing as it really restricts updates to just nodes. The caveat of having this setting enabled means things not referenced to the node in an "entity reference" way like path aliases and redirects don't get triggered as part of node updates. I personally recommend disabling that setting.
Comment #7
shrop commentedThanks for the updates @apmsooner. We will test this as a next step.
For the "Only trigger builds for published content" not being set, what would be a process to ensure live content isn't published or is it covered via Fastbuilds publish/preview payloads?
Comment #8
slydevil commentedPatch works great!
Comment #9
lisagodareThis patch appears to work great for our needs.
We don't want to use Entity Reference Revisions fields, because we don't want to associate a specific revision of a related entity on the relating entity. This is because multiple different entities may relate to it, and we don't want them each showing a different revision. They should all show the same revision - either the default revision, if published, on the 'live' build; or the latest revision, published or not, on the 'preview' build.
Comment #11
apmsooner commentedMerging to dev.
Comment #12
apmsooner commented