Stripogram or similar in core
What do people (especially Chris) think of making ChrisW's stripogram part of the core of Zope. Just discussing this with some colleagues today and we got onto a marshalling data and it occured to us it would be nice to do something like <input type="text" name="something:html:p:br"> that would only allow p and br in the html. Ok, its easy to get around with a fake form, but how about being able to only specify certain html tags in metadata in the CMF. Having HTML Parser and maybe those stripogram functions should be easy to integrate and provide Zope with a standard security mechanism for these issues. If people agree this a good idea I'll happily drive this forward. Cheers. -- Andy McKay.
Andy McKay wrote:
What do people (especially Chris) think of making ChrisW's stripogram part of the core of Zope.
I think it rocks :-)
Just discussing this with some colleagues today and we got onto a marshalling data and it occured to us it would be nice to do something like <input type="text" name="something:html:p:br"> that would only allow p and br in the html. Ok, its easy to get around with a fake form, but how about being able to only specify certain html tags in metadata in the CMF.
That's a cool syntax but it's a bit too 'magik' for me. That magik could be alleviated by something documenting the whole <input name="fish:list/x"> or maybe a project describing what those things after the colon should do and where they should be documented. personally, I don't think it'll scale to html filtering. What happens when you want to get the allowed tags from a property of another object?
Having HTML Parser and maybe those stripogram functions should be easy to integrate and provide Zope with a standard security mechanism for these issues.
Hmmm, how's this for a plan: 1. Document the :something options fully. 2. Add a :html that behaves as you describe 3. Fix the bug that means :date won't accept an empty value. 4. expose the above stuff in a coersion module that can be imported into python scripts, that would mainly have one function: coerce def coerce(from,to,**kw): eg: from coersion import coerce x='1234' y=1234 z='10/6/01' a='' b='<b>x,y</b>' coerce(x,'int')==y==1234 coerce(y,'string')==x=='1234' coerce(z,'date')==DateTimeObject coerce(a,'date')==DateTimeObject (or maybe None, but I favour a DateTime object that actually has a NULL value) coerce(b,'html',tags=['i'])=='x,y' cheers, Chris
That's a cool syntax but it's a bit too 'magik' for me. That magik could be alleviated by something documenting the whole <input name="fish:list/x"> or maybe a project describing what those things after the colon should do and where they should be documented.
Yeah it is a little. Just thinking of ideas here.
personally, I don't think it'll scale to html filtering. What happens when you want to get the allowed tags from a property of another object?
Hmm true of course it could just be <input name="fish:list<dtml-var "_.string.join(allowedHtml,'/')">" etc> or something
Hmmm, how's this for a plan:
1. Document the :something options fully.
2. Add a :html that behaves as you describe
3. Fix the bug that means :date won't accept an empty value.
Thats related?
4. expose the above stuff in a coersion module that can be imported into python scripts, that would mainly have one function: coerce
Hang on a sec...
def coerce(from,to,**kw):
eg: from coersion import coerce
x='1234' y=1234 z='10/6/01' a='' b='<b>x,y</b>'
coerce(x,'int')==y==1234 coerce(y,'string')==x=='1234' coerce(z,'date')==DateTimeObject coerce(a,'date')==DateTimeObject (or maybe None, but I favour a DateTime object that actually has a NULL value) coerce(b,'html',tags=['i'])=='x,y'
Whats wrong with just int and str etc... Is your idea here just to get everything in one place and one class? Other than that Im not sure of the value.. ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Andy McKay" <andym@ActiveState.com> Cc: <zope-dev@zope.org> Sent: Saturday, October 27, 2001 3:48 AM Subject: Re: [Zope-dev] Stripogram or similar in core
Andy McKay wrote:
What do people (especially Chris) think of making ChrisW's stripogram
part
of the core of Zope.
I think it rocks :-)
Just discussing this with some colleagues today and we got onto a marshalling data and it occured to us it would be nice to do something like <input type="text" name="something:html:p:br"> that would only allow p and br in the html. Ok, its easy to get around with a fake form, but how about being able to only specify certain html tags in metadata in the CMF.
That's a cool syntax but it's a bit too 'magik' for me. That magik could be alleviated by something documenting the whole <input name="fish:list/x"> or maybe a project describing what those things after the colon should do and where they should be documented.
personally, I don't think it'll scale to html filtering. What happens when you want to get the allowed tags from a property of another object?
Having HTML Parser and maybe those stripogram functions should be easy to integrate and provide Zope with a standard security mechanism for these issues.
Hmmm, how's this for a plan:
1. Document the :something options fully.
2. Add a :html that behaves as you describe
3. Fix the bug that means :date won't accept an empty value.
4. expose the above stuff in a coersion module that can be imported into python scripts, that would mainly have one function: coerce
def coerce(from,to,**kw):
eg: from coersion import coerce
x='1234' y=1234 z='10/6/01' a='' b='<b>x,y</b>'
coerce(x,'int')==y==1234 coerce(y,'string')==x=='1234' coerce(z,'date')==DateTimeObject coerce(a,'date')==DateTimeObject (or maybe None, but I favour a DateTime object that actually has a NULL value) coerce(b,'html',tags=['i'])=='x,y'
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Andy McKay wrote:
personally, I don't think it'll scale to html filtering. What happens when you want to get the allowed tags from a property of another object?
Hmm true of course it could just be <input name="fish:list<dtml-var "_.string.join(allowedHtml,'/')">" etc> or something
No offence, but I feel a bit ill having just read that ;-)
3. Fix the bug that means :date won't accept an empty value.
Thats related?
Well, same areas, birds and stones and all ;-)
def coerce(from,to,**kw):
Whats wrong with just int and str etc...
true...
Is your idea here just to get everything in one place and one class? Other than that Im not sure of the value..
yeah, prettymuch... there are builtins like int() and str() but there isn't a generic way of saying "I have this object of this type, I want it to be an object of this type" and I think there should be, given the number of different times and ways I've seen people solving this problem... cheers, Chris
Just discussing this with some colleagues today and we got onto a marshalling data and it occured to us it would be nice to do something like <input type="text" name="something:html:p:br"> that would only allow p and br in the html. Ok, its easy to get around with a fake form, but how about being able to only specify certain html tags in metadata in the CMF.
You seem to be aware of the fact, but I'd like to point it out explicitely: from a security point of view, this is completely useless. As HTML stripping is often done for security reasons, I fail to see the interest in such a feature. (BTW the :required field is also completely useless for security, and because it's misleading for beginners I even think it's downright harmful). -- Florent -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
You seem to be aware of the fact, but I'd like to point it out explicitely: from a security point of view, this is completely useless. As HTML stripping is often done for security reasons, I fail to see the interest in such a feature.
That depends where you do the checking, yes html validation in just a form is not as secure as checking at the application level. What I am suggesting is adding the HTML validation framework into the core of Zope so people can add checking to any level of their application as they wish. Making a standard interface to this gives a the developer chance to put the checking in at the level they choose. For example OFS.PropertyManager in standard Zope, or parts of say the Workflow in CMF. Form marshalling is just one of the possible uses... -- Andy McKay
Andy wrote:
You seem to be aware of the fact, but I'd like to point it out explicitely: from a security point of view, this is completely useless. As HTML stripping is often done for security reasons, I fail to see the interest in such a feature.
That depends where you do the checking, yes html validation in just a form is not as secure as checking at the application level. What I am suggesting is adding the HTML validation framework into the core of Zope so people can add checking to any level of their application as they wish. Making a standard interface to this gives a the developer chance to put the checking in at the level they choose.
If it's easy to get to I could also use it from Formulator, which, though I don't guarantee perfect security, at least has a design which makes it far less easy to fool than the Zope marshalling :foo thing (which you can fool just by writing your own HTML form). All you'd need is add a HTMLField to the system which has the right knobs to set what you exactly want to allow in entered HTML -- that's also a far better user interface than thinking up yet another marshalling :html:foo:bar strategy.. Anyway, just a module that I can import from Python that exposes the functionality would already be worth a lot having in the core; I'm loath to introducing dependencies on non-core stuff in Formulator, as it's aiming to be a very fundamental product that just should work out of the box. The only non-core dependency right now in on TALES, but it still works without it; you can also use Core Session Tracking in a simple way. Once Zope 2.5 is out I plan to start depending on sessions and TALES a lot more though, as they have those in the core. Regards, Martijn
Martijn Faassen wrote:
Anyway, just a module that I can import from Python that exposes the functionality would already be worth a lot having in the core;
That would be my preference... but the question is should it be core Zope or core Python. I mean, the type of functionality we're talking about is pretty generically useful. I wonder if python has anything similar in it or whether we should come up with something? (I have old code lying around for this by the way, so I don't think it'll be that hard...) cheers, Chris
Chris Withers wrote:
Martijn Faassen wrote:
Anyway, just a module that I can import from Python that exposes the functionality would already be worth a lot having in the core;
That would be my preference... but the question is should it be core Zope or core Python. I mean, the type of functionality we're talking about is pretty generically useful.
I would like it at least as a TTW configurable/instanciable (does that word exist?) zope product. It could allow - configuration of "forbidden" words in a textbox, alternativly using a "allow" policy (that might get hard). - a pre-cooked "secure html" config - possibility to write a custom parser/filter in python script/external method and it would allow something like <dtml-var someting filter="my_html_cleaner"> and <dtml-if "my_html_cleaner.is_valid('my_text')"> where is_valid(input_string) only checks if is_valid(imput_string) == input_string. The reason why I think it should be TTW configurable is that people not being able to pure python should also be in the position to use a security feature. Would this be compatible with ZPT etc.? Certainly, this doesn't rule out to implement the core funtionality as a pure python module. cheers, oliver
So, in this validation framework, do you envision having a parameter-validating routine being invoked whenever a publicly-exposed method is called by DTML methods, or did you want to focus on mere HTML form validation/stripping? I'm asking because I've had situations when I've needed the ability to restrict access to methods based on the values of their parameters -- that's a little more fine-grained than the current security machinery allows. I've always thought that it might be nice to provide a hook for each method in a Zope class (similar to declarative security statements), and to use this hook to validate the parameters, according to the needs of the user. For string parameters, perhaps we can also have the ability to specify a "filter" -- something like a search and replace statement, with Sed-like syntax. "Andy" <andy@agmweb.ca> wrote:
That depends where you do the checking, yes html validation in just a form is not as secure as checking at the application level. What I am suggesting is adding the HTML validation framework into the core of Zope so people can add checking to any level of their application as they wish. Making a standard interface to this gives a the developer chance to put the checking in at the level they choose.
Ivan Raikov wrote:
security machinery allows. I've always thought that it might be nice to provide a hook for each method in a Zope class (similar to declarative security statements), and to use this hook to validate the parameters, according to the needs of the user.
Now that's a brilliant idea :-) Could you stick that in a Proposal and get it implemented? I'd love to use it...
For string parameters, perhaps we can also have the ability to specify a "filter" -- something like a search and replace statement, with Sed-like syntax.
Ah, but surely the hookable method you propose could be used to doing any filtering required. This'd be my idea: from coersion import coerce def checkParms(self,args,kw): if args: raise TypeError,'Only keyword arguments allowed' if len(kw.keys())>1: raise TypeError,'Too many parameters supplied' param1 = kw.get('param1','') param1 = coerce(param1,'html',tags=self.allowed_tags) return ((),{'param1':param1}) def myClass(Folder): security = ClassSecurityInfo() security.declarePublic('myMethod') security.setParameterChecker('myMethod',checkParms) def myMethod(self,param1): ...do stuff... I just have a feeling that it might make your app crawl though :-( cheers, Chris
Now that's a brilliant idea :-) Could you stick that in a Proposal and get it implemented? I'd love to use it...
Write a proposal -- yes. Get it implemented -- I'll try :-)
Ah, but surely the hookable method you propose could be used to doing any filtering required. This'd be my idea:
param1 = kw.get('param1','') param1 = coerce(param1,'html',tags=self.allowed_tags) return ((),{'param1':param1})
Hm, I've never thought of using coerce for that purpose; I've always thought it's used only for math operations... Anyway, when I proposed the filter methods, I meant that we can still use the hook mechanism, but provide a number of pre-defined, stock methods that people can use (kinda like the __coerce__ methods from your example).
I just have a feeling that it might make your app crawl though :-(
Hey, I never said it'll be fast 8-) But seriously, while I don't know how fast would Python filtering be, if there are any performance issues, I think a primitive HTML parser written in C can take care of most of them.
Hello, I've created a proposal on dev.zope.org, regarding methods argument validation -- an extension to Zope's security framework, which would allow for validating method arguments, before they are passed to the actual methods. This will simplify things such as HTML form validation, etc. You can read the proposal at: http://dev.zope.org/Wikis/DevSite/Proposals/MethodArgumentsValidation -Ivan Raikov
participants (8)
-
Andy -
Andy McKay -
Chris Withers -
Florent Guillaume -
Ivan Raikov -
Martijn Faassen -
Oliver Bleutgen -
Steve Alexander