Fix client-size databag hash-mashing #147
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@jkeiser this fixes a compatibility issue with the normal chef server.
The issue is that setting data_bag_item to just the raw data will return a non-serialized data_bag_item.
This will cause the chef-client to load it as a hash instead of loading it as an actual data_bag_item object.
This will limit access of the data bag item to string only, where actual data_bag_item objects are mashes, and will support both string and symbolic access.
The practical problem here is that real cookbooks may use symbols, or a combination of symbols and strings to look up databags, as is the case with some of our cookbooks. This makes it impossible to use chef-zero without monkey patching.
I'm open to a better solution. Perhaps limiting the conditional below so that it will just ignore the GET method?
note this breaks data bag searching according to the tests, and I'm not sure why. There's probably a better fix.