July 1999 - Zope-Dev

DCOracle: writing blobs with ' and "
by Andreas Jung 09 Jul '99

09 Jul '99

I need to write some HTML documents into a table with a LONG RAW field. I must I convert my ' and " to put the document into the database. In every case my execute() fails with "missing comma" or other strange errors. Any idea ? Thanks, Andreas -- _\\|//_ (' O-O ') ------------------------------ooO-(_)-Ooo-------------------------------------- Andreas Jung, Saarbrücker Zeitung Verlag und Druckerei GmbH Saarbrücker Daten-Innovations-Center Gutenbergstr. 11-23, D-66103 Saarbrücken, Germany Phone: +49-(0)681-502-1563, Fax: +49-(0)681-502-1509 Email: ajung(a)sz-sb.de (PGP key available) -------------------------------------------------------------------------------

1 0

Propertysheets not working
by Jason Spisak 09 Jul '99

09 Jul '99

Zopemisters, Not sure if this is a bug. Is anyone else experienceing this: I add a ZClass. Then add a propertysheet called "Basic" (Using the default as much as possible:) Then when I call propertysheets.Basic.manage_editProperties, I get the AttributeError on "Basic". I searched the Collector and didn't see anything like it exaclty. Bug? All my best, Jason Spisak webmaster(a)mtear.com

2 6

Re:Propertysheets not working
by Jason Spisak 08 Jul '99

08 Jul '99

My experience is the same. Let me know what happens. Jason Spisak webmaster(a)mtear.com thegeek(a)hushmail.com wrote: > > There is definately a problem. I _think_ it only happens when your ZClass inherits from something else. If your experience contradicts that, I'd like to hear it. I'm trying to get Jim to fix it at this very moment. > > Mike. > > At Wed, 07 Jul 1999 11:21:23 -0800, Jason Spisak <webmaster(a)mtear.com> wrote: > > >Zopemisters, > > > >Not sure if this is a bug. Is anyone else experienceing this: > > > >I add a ZClass. Then add a propertysheet called "Basic" (Using the > >default as much as possible:) Then when I call > >propertysheets.Basic.manage_editProperties, I get the AttributeError on > >"Basic". I searched the Collector and didn't see anything like it > >exaclty. Bug? > > > >All my best, > > > >Jason Spisak > >webmaster(a)mtear.com > > > >_______________________________________________ > >Zope-Dev maillist - Zope-Dev(a)zope.org > >http://www.zope.org/mailman/listinfo/zope-dev > > > >(For non-developer, user-level issues, use the companion list, > >zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) > > > > Get HushMail. The world's first free, fully encrypted, web-based email system. > Speak freely with HushMail.... http://www.hushmail.com -- Jason Spisak Director Implementation/Development Masterson, Tate & Associates 6151 West Century Boulevard #928 Los Angeles, CA 90045 http://www.mtear.com

1 0

Propertysheets
by Jason Spisak 08 Jul '99

08 Jul '99

I just did an update. It still seems broken, differently, but still broken. Here's the traceback when I have a propertysheet named "properties" and a string property "first_name"  in the add method. <STRONG>Error Type: TypeError</STRONG><BR> <STRONG>Error Value: unexpected keyword argument: first_name</STRONG><BR> </P> <!-- Traceback (innermost last): File /home/mike_weltz/Zope/lib/python/ZPublisher/Publish.py, line 256, in publish_module File /home/mike_weltz/Zope/lib/python/ZPublisher/Publish.py, line 161, in publish File /home/mike_weltz/Zope/lib/python/ZPublisher/mapply.py, line 154, in mapply (Object: PersonClass_add) File /home/mike_weltz/Zope/lib/python/ZPublisher/Publish.py, line 98, in call_object (Object: PersonClass_add) File /home/mike_weltz/Zope/lib/python/OFS/DTMLMethod.py, line 150, in __call__ (Object: PersonClass_add) File /home/mike_weltz/Zope/lib/python/OFS/DTMLMethod.py, line 145, in __call__ (Object: PersonClass_add) File /home/mike_weltz/Zope/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: PersonClass_add) File /home/mike_weltz/Zope/lib/python/DocumentTemplate/DT_With.py, line 148, in render (Object: PersonClass.createInObjectManager(REQUEST['id'], REQUEST)) File /home/mike_weltz/Zope/lib/python/DocumentTemplate/DT_Util.py, line 315, in eval (Object: propertysheets.properties.manage_editProperties( first_name=REQUEST['first_name'])) File <string>, line 0, in ? TypeError: (see above) Also, the ZClasses I made yesterday give me KeyErros when I try to delete or change the propertysheet. All my best -- Jason Spisak webmaster(a)mtear.com

1 0

RE: [Zope-dev] Making objects publishable
by Michel Pelletier 08 Jul '99

08 Jul '99

> -----Original Message----- > From: Adrian Graham [mailto:aag@stanford.edu] > Sent: Tuesday, June 29, 1999 10:31 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Making objects publishable > > > I am in the process of trying to make a simple "Hello World" object > publishable. Currently I am using the tutorial entitled > "Approaching the > Zope Product API." In one section of the tutorial it appears to give > instructions regarding making an object publishable, and testing that > object with the debugger. However, it remains unclear to me how I > actually install this object in the Zope system, so that it > is available > on the Web. At this point I am not interested in making this object a > Product, but rather just a published object. Any instructions > regarding > this would be greatly appreciated (or pointers to documentation, if > there is something I've overlooked). > Publishing just a straight object on the web does not involve Zope, however, it does involve two things 1) a webserver, and 2) ZPublisher, which is the Object Request Broker for Zope. ZPublisher publishes modules over various network protocols. If you think about it, Zope is just one (really) big python module. To ZPublisher, there is no difference between your python module and Zope's. So, the quick and dirty way to publish your module would be with the quick and dirty webserver that comes with Zope, ZopeHTTPServer. The synopsis of the command to do this is: ZopeHTTPServer.py [-p <port>] [-t] [-h <host address>] <path to module> var=value,] <path to module> is the path to the module you want to publish. The URL then would be: http://machine:port/Module/Object -Michel > Adrian Graham > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

3 3

Re: [Zope-dev] Enhancing Zope's security model
by David Jacobs 07 Jul '99

07 Jul '99

Hi Christopher! Nice to meet you. I hope I can be helpful to you. See responses below. ----- Original Message ----- From: Christopher Petrilli <petrilli(a)digicool.com> > Yes, that's my bag-o-tricks, and probably a big chunk of why I'm here... I > left Xcert's PKI consulting group to come to Digital Creations. I'll try > and make a broad stroke at some of the ideas that I've been thinking > about---it just takes time (or money). With respect to time, I have a day a week for the next 9 to 12 months to dedicate to the problem. I am pursuing my dissertation (course work is done :-) on creating a security model for web based applications and my company has given me a day off a week to work on it. Zope seemed the farthest along in providing the rest of the infrastructure a web based security model would require. I have a 20 year background in object oriented programming (mostly C++) and security but have not done much in Python. > Traditional web servers have no security MODEL :-) having said that, I can > only agree whole-heartedly here. One of the things I'm working on slowly > is creating a full UML model of the security model implemented in Zope. > Then we can better discuss changes to the model. I'm a big believer in > formalization of the security model, as opposed to the purely textual "well, > we check X here". What tool are you using for your UML modeling? I must admit I have not kept up with UML. The last time I was heavy into case tools was back in 1992 using Rational Rose when Booch and Co. where still duking it out over the icons and fomalisms. I would love to see what you have so far or even any notes you have electronically. > This is a good thing, it also is necessary as we begin to integrate some of > the concepts introduced in the PKI world. We've already started to work on > how do you define roles and fit anonymous users into them. Also, how do you > separate the identification stage from the authentication stage. For > example, the path of a user through the security model: > > 1. 100% anonymous, unknown person > 2. Identifiable anonymous person (same person, but not sure who) > 3. Identified person, but not authenticated > 4. I&A person, but not authorized > 5. Authorized > > At any point, you should be able to bind that "individual" to a role. I would add their location and the kind of authentication is also important. For example many sites, especially digital library sites use the user's ip domain to determine what role they are assigned to. You might also want to assign different roles based on whether they have authenticated with a password in the clear or a password over SSL or a client certificate (not sure if this is useful). > Now, as you talk about being able to define a "permission" that has > intelligence to it, and I'm not sure how to do that without having a huge > impact on performance, but it is an interesting idea, especially as you try > and translate X.509 certificate information (i.e. DN + LDAP) into a set of > Roles. I'm not sure which concept you were referring to here :-). > > Provide for resolution rules for when positive and negative authorization > > conflict. > > * (e.g. lower in the object hierarchy overrides inherited auths, negative > > overrides positive, order dependent) > > First glance says this is 1) largely accomplished by acquisition as it is, > 2) too complex if it isn't as it introduces yet another concept that the > user must grasp. I agree the utility versus complexity is pretty low. At most it might be useful to offer a couple of predefined resolution modes with hooks to allow people to put in their own if they really want it. > The single largest flaw with many security solutions is they aren't obvious, > and in their obtuosity they only create more problems. Perhaps I'm simply > not understanding this. Want to write some pseudo code, er... Python? I agree whole heartedly. If you read the literature, people have come up with some amazing languages for expressing authorizations in an object oriented fashion, but god help the poor user who has to actually write real world authorizations in those languages. My desire is to try and bring some of these concepts "down to earth" and make them useful. > > Allow time restrictions on user/role associations or method/role > > associations (duration or cyclical restrictions) > > * This would allow you to say Joe is a Manager from June 1 to June 30th. > > I can imagine this being useful. More importantly, Joe is only a manager > from 8am-5pm M-F. This is a very common thing. > > > * This would allow you to say the Pay Payroll method can only be run on > > Friday's. > > This is probably best enforced at the "application" layer as opposed to the > framework layer. But perhaps there should be a way to have a separation of > the security "check" from the DTML itself. I think we will find that many of the features we think up may not have broad appeal. While that may be reason enough not to make them a "standard" feature, I agree that the framwork should still support plugging in the functionality via an API or standard security "check" concept that you brought up. > > Allow actions to be associated with an authorization event. > > * on success (e.g. write audit entry in log) > > * on failure (e.g. write audit entry in log and call routine that checks for > > excessive failures and pages sys admin if over the threshold.send email) > > Perhaps exposure of the new ZLOG framework at the DTML level would be > useful? Simply use a <dtml-call "auditme('information here')"> ? Upon further reflection, I would change this a little. Instead of allowing arbitrary actions, I would restrict it to just auditing events. I still think it would be useful to abstract it out of the DTML level though. Wouldn't it be nice to be able to log SQLMethod's and other zope objects?. All analysis of the events would be the responsability of a process outside of Zope such as an intrusion/fraud detection system. > > Allow expressions that include object values to play in the authorization > > decision. > > * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an > > EV method) if the EV.amount is less than $2500 and the EV.author is not the > > AUTHENTICATED_USER. > > Scared :-) Again, perhaps an abstract concept of a property on an object > that can on the *rare* occasion that it is needed could be called? Yes this is scary :-). It is also one of the most powerful. When you consider supporting almost any workflow based application, this becomes a necessity. This is because the state of an object often directly affects what and who can act on it. Thanks again for your response! David

1 0

Enhancing Zope's security model
by David Jacobs 07 Jul '99

07 Jul '99

Is anyone currently working on enhancing Zope's security model? Traditional web servers have horrible security model's for the application designer. They leave almost all the security work to be done by the application itself. With Zope abstracting all access into a nice object oriented fashion, much more powerful models are possible. What you guys have done with users, permissions and roles is already far ahead of other web servers. I am interested in taking it a step further to remove even more security code that currently resides in dtml scripts. My vision is to provide the following capabilities. Provide for positive and negative authorizations. * We may want to give a role Employees access to a method, but not if the user is also in the role Bad Boys. Provide for resolution rules for when positive and negative authorization conflict. * (e.g. lower in the object hierarchy overrides inherited auths, negative overrides positive, order dependent) Allow time restrictions on user/role associations or method/role associations (duration or cyclical restrictions) * This would allow you to say Joe is a Manager from June 1 to June 30th. * This would allow you to say the Pay Payroll method can only be run on Friday's. * This is useful in that you don't have to remember to remove Joe from the role. It also helps when looking at audit logs you can see that he was authorized to perform those functions during that time. Allow actions to be associated with an authorization event. * on success (e.g. write audit entry in log) * on failure (e.g. write audit entry in log and call routine that checks for excessive failures and pages sys admin if over the threshold.send email) Allow expressions that include object values to play in the authorization decision. * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an EV method) if the EV.amount is less than $2500 and the EV.author is not the AUTHENTICATED_USER. What do people think? Does this functionality sound useful? Do certain features call louder than others. I believe these features will make Zope MUCH more attractive for developing intranet applications, which typically have much more complex security requirements than public web sites do. I realize that most if not all of these features can be accomplished by coding in dtml. I would like to see much of that abstracted out into the security interface so that security policies can be more easily changed. I also realize that besides implementation, there is also the problem of coming up with a reasonable user interface that does not swamp the average person with possibilities. Good default behavior is necessary, with the full complexity of options only showing if the application designer asks for it. I've started familiarizing myself with the source code but have a ways to go. Obviously I would be making lots of changes in the access control directory, but it looks like a lot of the security framework is also embedded into the Zope objects like Folder and Document Objects. Any tips on code to pay special attention to or code that I can safely ignore would be greatly appreciated. Thanks in advance for any comments. David Jacobs MITRE Corporation

2 2

Re: [Zope-dev] Enhancing Zope's security model
by Christopher Petrilli 07 Jul '99

07 Jul '99

> Is anyone currently working on enhancing Zope's security model? Yes, that's my bag-o-tricks, and probably a big chunk of why I'm here... I left Xcert's PKI consulting group to come to Digital Creations. I'll try and make a broad stroke at some of the ideas that I've been thinking about---it just takes time (or money). > Traditional web servers have horrible security model's for the application > designer. They leave almost all the security work to be done by the > application itself. With Zope abstracting all access into a nice object > oriented fashion, much more powerful models are possible. Traditional web servers have no security MODEL :-) having said that, I can only agree whole-heartedly here. One of the things I'm working on slowly is creating a full UML model of the security model implemented in Zope. Then we can better discuss changes to the model. I'm a big believer in formalization of the security model, as opposed to the purely textual "well, we check X here". > What you guys have done with users, permissions and roles is already far > ahead of other web servers. I am interested in taking it a step further to > remove even more security code that currently resides in dtml scripts. This is a good thing, it also is necessary as we begin to integrate some of the concepts introduced in the PKI world. We've already started to work on how do you define roles and fit anonymous users into them. Also, how do you separate the identification stage from the authentication stage. For example, the path of a user through the security model: 1. 100% anonymous, unknown person 2. Identifiable anonymous person (same person, but not sure who) 3. Identified person, but not authenticated 4. I&A person, but not authorized 5. Authorized At any point, you should be able to bind that "individual" to a role. > Provide for positive and negative authorizations. > * We may want to give a role Employees access to a method, but not if the > user is also in the role Bad Boys. This is something I miss too... it would be nice to be able to "allow/deny" permissions overriding acquisition through this... so each setting would have three possible positions: * On (allow) * Off (deny) * Acquire Now, as you talk about being able to define a "permission" that has intelligence to it, and I'm not sure how to do that without having a huge impact on performance, but it is an interesting idea, especially as you try and translate X.509 certificate information (i.e. DN + LDAP) into a set of Roles. > Provide for resolution rules for when positive and negative authorization > conflict. > * (e.g. lower in the object hierarchy overrides inherited auths, negative > overrides positive, order dependent) First glance says this is 1) largely accomplished by acquisition as it is, 2) too complex if it isn't as it introduces yet another concept that the user must grasp. The single largest flaw with many security solutions is they aren't obvious, and in their obtuosity they only create more problems. Perhaps I'm simply not understanding this. Want to write some pseudo code, er... Python? > Allow time restrictions on user/role associations or method/role > associations (duration or cyclical restrictions) > * This would allow you to say Joe is a Manager from June 1 to June 30th. I can imagine this being useful. More importantly, Joe is only a manager from 8am-5pm M-F. This is a very common thing. > * This would allow you to say the Pay Payroll method can only be run on > Friday's. This is probably best enforced at the "application" layer as opposed to the framework layer. But perhaps there should be a way to have a separation of the security "check" from the DTML itself. > * This is useful in that you don't have to remember to remove Joe from the > role. It also helps when looking at audit logs you can see that he was > authorized to perform those functions during that time. No disagreement, but we have to balance power and speed and usability. > Allow actions to be associated with an authorization event. > * on success (e.g. write audit entry in log) > * on failure (e.g. write audit entry in log and call routine that checks for > excessive failures and pages sys admin if over the threshold.send email) Perhaps exposure of the new ZLOG framework at the DTML level would be useful? Simply use a <dtml-call "auditme('information here')"> ? > Allow expressions that include object values to play in the authorization > decision. > * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an > EV method) if the EV.amount is less than $2500 and the EV.author is not the > AUTHENTICATED_USER. Scared :-) Again, perhaps an abstract concept of a property on an object that can on the *rare* occasion that it is needed could be called? You bring up some good ideas, discussion is good on this. Christopher -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Zope Creation Time
by Jason Spisak 07 Jul '99

07 Jul '99

Zopsters, I know that there is a bobobase_modification_time attribute. Does anyone know of a bobobase_create_date/time attribute, or if Zope stores such information? On a completely separate note, twice the ZODB has told me that a property name was in use when it was no where else, and then gave me key errors on that object for a period of about 5 minutes, or until I clicked on the right compination, I guess. It seemed like a thread issue. I am the only one using Zope, but since it wen a away and let me enter it eventually I am spooked out. Anybody experience this? A temporary KeyError? CVS sheckedout and recompiled as of 9:00 am PST 07/06/1999 All my best, Jason Spisak webmaster(a)mtear.com

2 1

RE: [Zope-dev] New ZPublisher Types
by Alexander Staubo 07 Jul '99

07 Jul '99

Also there are some gross HTML errors (check out the font size/type for last 2/3 of the document, starting at "Here is the HTML input form"). -- Alexander Staubo http://www.mop.no/~alex/ "What the hell, he thought, you're only young once, and threw himself out of the window. That would at least keep the element of surprise on his side." --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_ >-----Original Message----- >From: zope-dev-admin(a)zope.org [mailto:zope-dev-admin@zope.org]On Behalf >Of Martijn Pieters >Sent: 7. juli 1999 04:08 >To: Pam Crosby; Cathi Davey; 'zope-dev(a)zope.org' >Subject: RE: [Zope-dev] New ZPublisher Types > > >At 20:08 05/07/99 , Pam Crosby wrote: >>Cathi, >>Your documentation has been added to the Trinkets Tutorial online at >>http://www.zope.org/Documentation/Reference/Trinkets/index_html > >Very nice! > >These changes are only available in the latest CVS release, >however. How >will a new developer be able to detect this from the documentation? > >Some errors: > >-- >RECORD > ><INPUT TYPE="text" NAME="person.name:record" SIZE="30"> > >The input tag for the name field is named >person.name:record:ignore_empty. The >:record part of the name indicates to Zope that the field should be >converted to a record before passing it to the published >method. A record >variable will be created called person and it will have an >attribute called >name. > >- Either: The first line should read: .. is named >person.name:record. The .. >- Or: the NAME field of the INPUT tag should read: >person.name:record:ignore_empty > >-- >RECORDS > >The records method is implemented: > > <P><H2>Member #1<H2></P><br> > <P>lease enter your name:<BR> > <INPUT TYPE="text" NAME="member.name:records:ignore_empty" >SIZE="30"><BR> > your email:<BR> > <INPUT TYPE="text" NAME="member.email:records:ignore_empty" >SIZE="30"><BR> > your age:<BR> > <INPUT TYPE="hidden" >NAME="myname.age:int:records:default" Value="0"<BR> > <INPUT TYPE="text" >NAME="member.age:int:records:ignore_empty"></P><BR> > <P><H2>Member #2</H2></P><BR> > <P>Please enter your name:<BR> > <INPUT TYPE="text" NAME="member.name:records:ignore_empty" >SIZE="30"><BR> > your email:<BR> > <INPUT TYPE="text" NAME="member.email:records:ignore_empty" >SIZE="30"><BR> > your age:<BR> > <INPUT TYPE="text" NAME="member.age:int:records:ignore_empty<a >href="records"">></P> > >In this sample the form asks for a name and age for two >different members >of a club. The part appears in each input tag. This type will >create a list >called members that will hold records (in this case it will hold two >records). Each record can have the attributes name and age. > >- The hidden field should read: .. >NAME="member.age:int:records:default" .. >- A newline before the line 'Member #2' would increase readability. > >-- > > > >-- >Martijn Pieters, Web Developer >| Antraciet http://www.antraciet.nl >| Tel: +31-35-7502100 Fax: +31-35-7502111 >| mailto:mj@antraciet.nl http://www.antraciet.nl/~mj >| PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------ _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://www.zope.org/mailman/listinfo/zope-dev (For non-developer, user-level issues, use the companion list, zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope )

1 0