XMLSecurityPolicyProvider never saves a backup of data it has downloaded
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Spotted while reading code and confirmed by Scott.
XMLSecurityPolicyProvider implements load(boolean), and the contract is that if you implement that then you take ownership of saving the data (confusingly enough, except for the base class in which the save is implemented in the deprecated load() function.
The net result is that we never save configurations loaded via the net to local storage.
The simple fix is to call ReloadableXMLFile::load() rather then ReloadableXMLFile::load(boolean). But I think it would be better to move all the function that is in load(boolean) to background_load() and still call ReloadableXMLFile::load(). This is what XMLAccessControl and is a paradigm I find more understandable.
Environment
None
Activity
Rod Widdowson June 8, 2016 at 4:35 PM
Fixed by 8661656b3
This does the old fashioned thing of opening a stream and then just telling the DOM to write itself there. Anything else gets complicated in the sp-lite world. Anyway the Xerces bug may get fixed and anyway nobody will put config out on the web which is unreadable.
Spotted while reading code and confirmed by Scott.
XMLSecurityPolicyProvider implements load(boolean), and the contract is that if you implement that then you take ownership of saving the data (confusingly enough, except for the base class in which the save is implemented in the deprecated load() function.
The net result is that we never save configurations loaded via the net to local storage.
The simple fix is to call ReloadableXMLFile::load() rather then ReloadableXMLFile::load(boolean). But I think it would be better to move all the function that is in load(boolean) to background_load() and still call ReloadableXMLFile::load(). This is what XMLAccessControl and is a paradigm I find more understandable.