Thanks for the update Chris. The flexible validation model makes sense - in the medium-to-long term I would also like to see TiddlyWeb ship with a default validator that allows for general HTML content, that does the usual Javascript stripping, matching HTML tags, and so on. Perhaps one that is easily configurable wrt which tags (and possibly attributes) it can take. Last I checked, this is a fairly common thing for sanitisation libraries to offer, so what I'm suggesting is a validator that is simply an adaptor into an existing sanitisation library.
On Jun 15, 7:22 pm, "[email protected]" <[email protected]> wrote: > trac ticket 866 <http://trac.tiddlywiki.org/ticket/866> discusses the > need for server-side sanitation and validation of tiddler content. > > My latest tiddlyweb commit to github starts work on a prototype for > such things. I'd appreciate some comments from interested parties. The > commit can be viewed at: > > <http://github.com/tiddlyweb/tiddlyweb/commit/ > 2e471d0bf8f6d81f9b3f91e37b2a535935ab683e> > > One of my concerns was, as usual, to make this extensible and > flexible, while also making it possible to have it not there at all > (as I feel too much validation runs contrary to the Wiki way). I think > what I've built gets this, but please confirm or deny as needed. I > also tried to take into account some of the comments in earlier > threads on this topic. > > The basic architecture goes like this: > > * There is a new constraint on policies called "accept". Like most of > the other constraints this is a list which can take roles, usernames, > and the special values "NONE" and "ANY". "accept" in this context > means "for the people in this list" accept the content without > sanitation or validation. The empty list means accept for everyone. > "ANY" means accept for any authenticated user. "NONE" means never > accept for anyone. > > * When content is not accepted, it is passed into a validator system. > The tiddler and the current WSGI environment are provided to a list of > methods which either modify the current tiddler (e.g. disabling any > javascript, or cancelling a strange content type, or removing curse > words, etc) or raises "InvalidTiddlerError" if the tiddler is not > worth having. > > * If the exception is raised it is reraised as an HTTP 409 (conflict) > that is sent to the user agent. > > * If no exception is raised the now modified tiddler is saved to the > store. > > * The validator methods are kept in an extensible module level list > called TIDDLER_VALIDATORS. At the moment it is empty, but this will > change soon enough. > > In the commit reference above are two validators in the new test files > that demonstrate in the simplest way possible how things can work. > > I hope this message makes some sense and the implementation as well. > If there is no sense to be found here, do let me know so I can > straighten things out. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
