Config tool mishandles JSON object-vs-string dichotomy
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
blocks
Checklist
hideActivity
Mike Taylor October 18, 2024 at 2:35 PM
End of week, I need to get the release out. So, @Wayne Schneider, I went ahead and assumed that the config-tool fix was good.
If you find it’s not, drop me a line and a we can revisit.
Mike Taylor October 17, 2024 at 2:18 PM
@Wayne Schneider I hate to hassle you, but getting this QAd is one of the last things I need before I can do the Ransoms release of mod-reporting.
Mike Taylor October 16, 2024 at 4:00 PM
Merged to master.
@Wayne Schneider, can you please verify that this now works as expected?
Mike Taylor October 16, 2024 at 3:59 PM
Fixed in a branch.
Mike Taylor October 16, 2024 at 1:47 PM
All right, time to stop over-thinking this, and consider it in operational terms.
I don’t want to change the behaviour of mod-reporting, which is working correctly as the back-end to the Reporting app, and risk breaking something that actual customers use.
I do want the
get/setoperations of the config tool to work as a pair with no need to mess about editing the textual form.
So the correct solution here is to modify the config-tool script itself to make sure it sets the configuration in the form that the destination module (mod-reporting) expects.
Details
Details
Assignee
Reporter
Tester Assignee
Priority
P3
As reported by @Wayne Schneider in https://index-data.atlassian.net/browse/DEVOPS-3367, the config tool extracts the
dbinfokey and unescapes the JSON that is in thevaluekey so that the key contains a JSON object rather than stringified JSON . That value needs to be JSON-escaped (i.e. remove line breaks, use \ to escape quotation marks) to be PUT, as something – whether mod-reporting or mod-settings is hard to say as neither logs an error though the config tool reports a 500 error -- expects thevaluekey to contain a string, not an object…