On Apr 3, 11:19 am, FND <[email protected]> wrote: > > Corrupting the data is pretty much exactly what we want here. > > [...] > > If somebody wants text/plain they can PUT text/plain to the server and > > it will be served back that way only. > > That sounds reasonable then. > (Are text/plain PUTs stored differently? I'll look into that to make > sure I properly understand this... )
Sorry, I got that slightly wrong: When a PUT to a tiddler happens, if the content-type is application/json or text/plain the content will be treated as if it is a json or text serialization of a Tiddler and a Tiddler object will be created. This means that when that tiddler title is requested later, it will be presented as wikitext or rendered wikitext. If some other content type is provided, the content will be preserved as is as a so-called binary tiddler. Some of these, e.g. text/html will need to be sanitized to prevent XSS type issues. > > Changing the data on the way in is easier. > > Absolutely. > That alone isn't a sufficient reason, of course... Barring truly compelling reasons to go with a harder solution, easy to code and easy to understand should be leading priorities. > > * The name of the field would be "sanitize_unless". > > * The default would be an empty list. If the list is empty then > > incoming content is not sanitized. > > [...] > > Seems good that way. > Minor concern: I know the name is not final yet, but interpreting > '"sanitize_unless": []' to mean "never sanitize" seems counterintuitive. The issue here is that we are trying to horn into the existing policy grammar thing that does not quite fit. If you can think of something that fits mo' betta' please shout out. The existing read, write, create, delete and manage constraints on the policy make statements of who can do what, and the empty list means the constraint is undefined, therefore there is no constraint. In each of those cases when the constraint is defined the grammar says "allow read for 'X'". In the sanitize case we do _not_ want to have to list users for who sanitizing should happen, as it is exactly the people we don't know whose content we wish to clean. So the thinking was "sanitze_unless you are special person (or role) X". Keep in mind that for the most part setting policies ought to be through an interface which can describe these things however one likes. > > Some might argue that the default should be NONE or ANY, but that, to > > me, is getting really anti-wiki. I'd rather default to openness and > > protect where necessary. > > I guess this depends on each individual instance's use case. Yes, but the software should have an opinion. > However, that could probably be solved with a simple (twanager?) plugin > which sets sanitize_unless to NONE or ANY when creating a bag. If you look at the docs on the Policy class you'll see that there's some thinking that perhaps there should be a default policy setting that comes from configuration. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
