On Apr 1, 6:46 pm, FND <[email protected]> wrote:
> > It is far more stable, predictable and performant to sanitize input
> > we get it and store the sanitized data in the datastore.
>
> While I generally agree, there's one point to consider here:
> One might argue that this sort of interference is corrupting the data.
> After all, you might not want to serve the contents as a TiddlyWiki or
> static HTML page, but simply as plain-text document - in which case
> there are no side effects.
Corrupting the data is pretty much exactly what we want here. This is
protection against people who could intentionally or otherwise break
things with their data. So we want to change the data. Changing the
data on the way in is easier.
It's in the case of incoming tiddlywiki text or HTML that we need to
most concerned. A static HTML page can contain destructive javascript.
We don't want that in some cases. Tiddlytext is going to get rendered
to HTML on the server or in the TiddlyWiki, we need to be careful with
it, in some cases.
If somebody wants text/plain they can PUT text/plain to the server and
it will be served back that way only.
But also see below.
> If I understand you correctly, content would be sanitized on a per-bag
> or per-tiddler basis.
It's on per-bag basis, and in the model I'm thinking the attribute
would be something like this (not sure of names yet):
* 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.
* If there are values in the list they would be usernames or roles (as
with the other constraints in policies). If the current user matches
the username or has the listed role, then their content would _not_ be
sanitized as it is pushed into the bag. For everyone else it would be.
* The value could also be the ANY or NONE values that are used on
other constraints. For ANY, any authenticated user would not get their
content sanitized, but GUEST would. NONE would mean that we sanitize
for everyone.
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.
> What, though, if you want a certain group of users (e.g. admins) to be
> able to submit code - would you then suggest using a separate bag in
> combination with a certain recipe cascade?
Does the above explain what I'm thinking? Does it seem reasonable?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
