Re: [Zope-dev] funky side-effects, possible bug in HTTPRequest.py
Jamie Heilman wrote: [major snippage] Hmmm, that means that this changes break exactly these applications, which, in order to be on the secure side, explicitly use REQUEST.form['bla'] more than once in a request, right. Ironic. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] version status
Jamie Heilman wrote: Chris Withers wrote: Jamie Heilman wrote: 100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection, Well, without that, they would never be able to view a page from a Zope site. That would make it tricky to log in ;-) By which I ment being assigned pre-allocated resources vs. allocating the resource during the request itself. I don't quite understand the nature of this DOS attack after the patch. You do requests with REQUEST['Zope-Versiom'] == big string. If I understand your code correctly (it was bash and perl afterall ;)) you create version i with a version name str(i)*50. It seems (to me) that the sole cause for this DOS is that zope stores the version names in memory, that means you get a memory consumption for all version name strings of 10*50 + 90*50*2 which is 95.000.000 bytes, which is roughly the 90M you reported. But why does zope store the version names even if the transaction is aborted, isn't that another bug? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] version status
Shane Hathaway wrote: Jamie Heilman wrote: Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted. Say it a little louder. Here is what I think you're saying: - Anonymous users can still open a versioned database connection (although now they can't use it) - Merely opening a versioned connection consumes resources - Zope does not free those resources as it should Can you confirm that's what you're seeing? Either we need to make Zope free the resources, or if that's not possible, we need a different strategy. If I may also add something else, it might be a good idea to limit the namespace where zope looks for a variable named Zope-Version. Both ZApplication.py and the patch look for this variable in the whole REQUEST, (i.e. via request.get(...)). I'd propose to change that to REQUEST.cookies.get(...). As it is, it violates the principle of least surprise and is also a tad inconsistent, because the patch even assumes that the Zope-Version variable came via a cookie (it tries to delete said cookie). This is not purely aesthetical reasoning, since cookies can be trusted a bit more than other variables coming from the request. You can't inject them from third party sites, for instance. Limiting the lookup only to REQUEST.cookies would also make client side trojan attacks a bit harder (not that you can't do much worse things with these kinds of attacks). cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Request method
Anitha George wrote: Hii Could any of you please tell me what is the request method used in Zope to go back to the page from where I have come. Plss do send a reply soonnn... Thanks Anitha Anitha, I think questions of this nature are better sent to [EMAIL PROTECTED] (zope-dev mostly means development _of_ zope, not with), I've set a Cc: accordingly. To answer your question, do you want to know the URI of the page the browser came from? That'd be REQUEST.HTTP_REFERER . Not that this is not reliable, though, because it depends on the client to send that information. HTH, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Chris Withers wrote: Shane Hathaway wrote: My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. On the weekend I had the idea that it's even easier. See http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 how to do that on an zope server. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity. This was my fear, and it's pretty shocking. Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-) Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer not to get ;). cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] what is manage_workspace supposed to do?
I've a problem with a product I'm writing and the way manage_workspace
works.
There's this code in App/Management.py:
def manage_workspace(self, REQUEST):
Dispatch to first interface in manage_options
options=self.filtered_manage_options(REQUEST)
try:
m=options[0]['action']
if m=='manage_workspace': raise TypeError
except:
raise Unauthorized, (
'You are not authorized to view this object.')
(*) if m.find('/'):
raise 'Redirect', (
%s/%s % (REQUEST['URL1'], m))
return getattr(self, m)(self, REQUEST)
My question is about the marked block. I'd guess that the intent is to
send a redirect if m (== options[0]['action']) contains a '/'.
But m.find('/') evaluates to false only if m[0] == '/', otherwise it
yields either -1 (which is true), if there's no '/' in m, or something
greater 0, if there's a slash after the first char.
Is this intended behavior or a bug?
cheers,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Shane Hathaway wrote: Brian Lloyd wrote: FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the join / leave versions permission (which is assigned only to managers by default. It will be interesting to find out how this can be accomplished. To use a version, you have to specify the version at the time of opening the database. Before opening the database, the application has no access to user accounts, let alone security settings. And you have to take acquisition into account folder1 some_object folder2 version2 some_object shouldn't be lockable into version2. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Dieter Maurer wrote: Oliver Bleutgen wrote at 2003-6-10 16:20 +0200: ... And you have to take acquisition into account folder1 some_object folder2 version2 some_object shouldn't be lockable into version2. Where did you ever read that the effect of versions were in any way restricted in correspondence with their own path? You are right. I hadn't looked at this code for a long time, now I checked in cvs, and this was changed (ca. 2 years ago). Now zope sends BASEPATH1 as cookie path, which makes the cookie indeed global. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
small summary and big plea was:(Re: [Zope-dev] Versions: should theydie?)
Ok, I still have the impression that not enough people are aware of the full implications of the version functionality as it is implemented in zope. So let me summarize. versioning-as-implemented-in-zope consists of two parts: First, there's the database backend part (which I know nothing about) with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). This resides where the db-connection is opened on the very start of every request. The second part is the Version product (capitalized to distinguish them) which is zope's mechanism to get a variable named 'Zope-Version' (==version_support) with the value of the path to the version object inside the REQUEST (by setting a cookie). Bad properties of this implementation: 1. The Join/Leave Versions permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition. Security implications: Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos. Big plea: Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone. Sorry for getting a bit worked up about that issue. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Casey Duncan wrote: One man's opinion: - Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them. I would suggest these approaches: 1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon. I had a bug in the collector for that in the 2.3.x times, before the db crashed, IIRC. I fear I'm bad at explaining the issue clear enough, so nobody cared. 2: develop a patch and submit it and/or check it in probably after vetting the change on a branch. I have definately not enough knowledge to get a fix for that which is acceptable speedwise. And removing the version support is probably not what you want ;). I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself. This is not my favorite issue, non of my sites is really affected by this because there only trusted users are able to write to the ZODB, so they could do much more harm in simpler ways. The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. This is the important thing that doesn't seem to get through. These implications _do_ apply! I would be very suprised if I wouldn't be able to inject versioned objects into zope.org, collector.zope.org or squishdot.org for example. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Aaah, big thanks for chiming in. *sigh of relief*. Shane Hathaway wrote: Casey Duncan wrote: The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6. My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. It's even worse. Just add Zope-Version=bla to your (or anyone elses) request, maybe handy for client side scripting attacks. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity. Well, there's still ControlPanel-Version Management, but you have first to know that it exists ;). Had that problem when this hit me quite a while ago. I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie and disabling the creation of Version objects, with an option to re-enable. +1 cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: shouldthey die?)
Dieter Maurer wrote: Oliver Bleutgen wrote at 2003-6-6 11:46 +0200: 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition. 3. is already implemented correctly (I think). I doubt it, since the code which causes the opening of a versioned db connection doesn't know anything about the path semantics of the value of 'Zope-Version'. Let's say you have aMethod aFolder aVersion and have entered the version at aFolder/aVersion and POST to aFolder/aMethod/manage_doSomething (manage_doSomething changes aMethod) your browser will send a 'Zope-Version' cookie with value 'aFolder/aVersion' (standards conform, since you are requesting an URL below '/aFolder', the path of this 'Zope-Version' cookie), and aMethod will be locked in that version. Not tested, but I would take a bet. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Versions: should they die?
Anthony Baxter wrote: Oliver Bleutgen wrote As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only). The problem lies in ZODB.ZApplication.ZApplicationWrapper def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ... As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here? I think that will only work if there's a Version with the specified name. Have you tried it? I have (with cookies), and it works always. Oh, and for added fun set a persistent cookie. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Versions: should they die?
[EMAIL PROTECTED] wrote: If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it). I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as official evil in ZMI. As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only). The problem lies in ZODB.ZApplication.ZApplicationWrapper def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ... As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Versions: should they die?
Paul Winkler wrote: To anyone not following the Problem committing zope 'version' objects thread on [EMAIL PROTECTED]: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? As I see it, you either have to disable the versioning functionality completely, or live with it. Raising a warning when people for instance add a Version object just gives the impression that you are safe if you don't use the Version product, which is wrong. If the version functionality would be disabled by default and could be enabled by a startup parameter without impacting performance, then this would be the way to go IMHO. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LOTS of roles?
Paul Winkler wrote: On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote: Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user user_id get's just the role user_id, instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets. Interesting idea... tell me if I'm wrong, but I see two obvious problems with this approach: 1) for one-role-per-user: we'd have to visit the security management for N objects in Zope and adjust the permissions every time we add a user. Whereas in my proposal, we only need to do that every time we add a site or change the tasks, which happens much less frequently. 2) for one-role-per-user, changing a user's privileges means wanding around the ZMI setting permissions on N objects. Whereas in my scheme, we can do that in one place (LDAP) by adding or removing a role or two. You might wind up with less roles and I bet administration is a lot easier. my guess is that in our case, the number of roles would be comparable. 200 sites * 10 tasks = 2000 roles 200 sites * 10 users = 2000 roles I think I still don't get all the characteristics of you application. So I'll try to post what I had in mind: - implement a kind of permission matrix: tasksxsites,i.e. permission 1X says that the user who has this permission is allowed to call taskX(site=1,...). Then in taskX you could check if the user has the permission 1X, and otherwise throw an exception. - write an UI which hides the existance of roles, instead let the admin assign permissions directly to users (by implictly creating one role named user_id with all the permissions the admin choose). Optionally give the admin some knobs to use permission templates or other helpers. Note that this could still be combined with normal roles for everything which has nothing to do with your sites. So I don't see why your point 1) and 2) could be an issue, unless you also need stuff like local roles for other things etc. - but that seems to be solvable through an UI too. Then you'd have sites*tasks permissions, and as many roles as you have users. And maybe you steered around the complexity problem w.r.t roles too. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LOTS of roles?
Paul Winkler wrote: On Sat, Feb 22, 2003 at 02:24:10PM +0100, Oliver Bleutgen wrote: With locations, do you mean physical locations of the clients (i.e. IP-adresses), or the locations of objects inside zope (i.e. /department1, /department2 etc.)? Both. Let's call them sites instead of locations, because they're physical sites: a discrete physical resource that our users need to manage. One user may have certain permissions at one of these sites, and different permissions at another. Unfortunately this is a required feature It's also true that there may be specific content and applications in zope which correspond to a specific physical site, but not to the whole group of sites. and that's why zope needs to be involved with such a complex security model. From that I gather that your sites don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope. [example snipped] The solution we are considering is to have one role per site per task. If we were to name the roles after the site and task identifiers, we'd end up with something like: User A has roles 1X, 1Y, 2Y, 2Z User B has roles 2X, 3X, 3Y, 3Z ... but this obviously leads to an explosion of roles. e.g. 10 tasks * 200 sites = 2000 roles. Hence my original question. :) [...] The other possibility I've considered is a custom UserFolder which assigns the user's roles dynamically depending on what physical site they are working on (which we can always find out). This seems less bulky - many fewer roles from Zope's perspective - but i'm concerned about introducing security bugs that might go unnoticed, and I've never written a UserFolder so I don't know how long it would take. There's a nice template for userfolder from ChrisW: http://www.zope.org/Members/NIP/SimpleUserFolder And I'm worried about session issues - if user A is doing some remote work for site 1 and then switches to site 2, would all of his roles be updated immediately and correctly? And we may need to allow a user to work on two sites *simultaneously* which would not be possible in this model. Well, for me roles are just a simplification/optimization for getting permissions of a user (for an object) for the sake of easier management. From the mapping user_id - set of permissions, we go to user_id - set of roles - set of permissions, where the last mapping is defined by mappings of the form role - set of permissions. This works, because for typical situations, you just need to define a handful of roles. Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user user_id get's just the role user_id, instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets. You might wind up with less roles and I bet administration is a lot easier. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LOTS of roles?
Paul Winkler wrote: more about our scenario: * We must anticipate users at hundreds of locations * there might be 10 or so users at each location * permissions can be grouped pretty well into tasks, but are specific to a location - permission to do a task at one location must not mean permission at all locations. To me this suggests several Roles per location, corresponding to the grouped tasks at that location. * each user might work from several different locations * each user might need different permissions when working at different locations * We have multiple applications, not all in zope, so LDAP is looking attractive. With locations, do you mean physical locations of the clients (i.e. IP-adresses), or the locations of objects inside zope (i.e. /department1, /department2 etc.)? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] PCGI?
Jamie Heilman wrote:
Leonardo Rochael Almeida wrote:
RewriteRule ^(.*)$ http://127.0.0.1:8080/VirtualHostBase/http/%{HTTP_HOST}:%{SERVER_PORT}/some/folder/VirtualHostRoot$1 [P,L]
This way you don't have to worry about what hostname the user uses to
access their site.
[security considerations snipped]
And here's an argument which is not security related:
This RewriteRule is broken, because HTTP_HOST might contain the port
number. IIRC, wget does this, and the HTTP RFC does allow that.
cheers,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server Control
Andy McKay wrote: 3. I've found at least two companies that run many, many zope servers on remote boxes all over the place and would like one ui to see the status of them all, I'm trying to see if i can get some $ out of them for the development :) If it's about monitoring, let me just mention nagios, to be found at http://www.nagios.org/ It's a very very nice monitoring app which I use for monitoring states of several servers. It can use external (command line) apps for monitoring. Maybe it would be of some use to develop an the app so that the clients for getting the status for zope servers could also be used as plugins for nagios. Encapsulating the classes used for getting the data from a zope server into a module would suffice, then one could write simple monitoring apps as described here: http://nagiosplug.sourceforge.net/developer-guidelines.html cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
Dieter Maurer wrote: You might use a SiteAccess access rule. Dieter, thanks for the suggestion. But I don't see how SiteAccess could help me here, maybe I'm missing something. Basically, what I want to do is to prevent zope from ever sending a unauthorized response to a clear text http request, instead it should send a redirect to a https://* URI, which would then send the unauthorized response, so that the browser dialog for basic authentication would only be trigger on a secure connection. I don't know where inside zope I could implement such a hook, that's why I posted here. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: AdaptableStorage
Shane Hathaway wrote: On the filesystem, the problem seems much more difficult, since there are no transactions. You'd like the kernel to send Zope a message anytime someone modifies a file in a certain hierarchy, but that would require kernel hacking. FWIW, since I had the same problem some time ago (which could be solved in another way), I dug out an url, which might be of interest - probably you already know about it: FAM, used by the two major open source desktop envs: http://oss.sgi.com/projects/fam/ It may at least help to make the whole problem more os independend. They have a lot of related pointers on their homepage. Btw. windows (=nt IIRC) already has the capability to notify on directory alteration events, without polling. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: AdaptableStorage
Shane Hathaway wrote: Oliver Bleutgen wrote: Shane Hathaway wrote: On the filesystem, the problem seems much more difficult, since there are no transactions. You'd like the kernel to send Zope a message anytime someone modifies a file in a certain hierarchy, but that would require kernel hacking. FWIW, since I had the same problem some time ago (which could be solved in another way), I dug out an url, which might be of interest - probably you already know about it: FAM, used by the two major open source desktop envs: http://oss.sgi.com/projects/fam/ It may at least help to make the whole problem more os independend. They have a lot of related pointers on their homepage. I've seen it before, but I don't think FAM is able to monitor an entire directory tree. It only monitors individual files. I'd really like to be wrong. :-) I think you are wrong, because the manpage (for IRIX) says otherwise. Additionally, it wouldn't be of much use for kde etc. if it only could monitor files. I think a filemanager would mainly be interested in directory changes (files added/deleted). Then there's also dnotify (also reference from the FAM site) - there's hope that the d isn't an acronym for file ;). I remember someting about recent 2.4.x versions having the prerequisites to use that. Btw. windows (=nt IIRC) already has the capability to notify on directory alteration events, without polling. Do you know what API? That would sure help. I don't have any expirience on win32, but just searched google. There's Win32::ChangeNotify for perl, described here http://www.xav.com/perl/site/lib/Win32/ChangeNotify.html and this seems to use ReadDirectoryChangesW, decribed here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/readdirectorychangesw.asp cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] question: forcing https for authentication
Jamie Heilman wrote: Well its true you can't prevent users from compromising their credentials, but you can prevent users from coming in the wrong door, as it were. I'm not clear on which one you really hope to accomplish, though from your proposed modifications it looks like the latter. Preventing users from compromising their creds can only be effectively done through education. For example, even if you used client certificates (which, afaik, are only used once an encrypted channel has been established) instead of basic auth there's nothing to stop a user from giving their cert and any requisite ancillary usage information (like the passphrase to decrypt it) to somebody else. Granted. I indeed want prevent users from coming in the wrong door. And it would really help if there wasn't a wrong door at all - therefore my question ;). The only ideas I have to tackle this without modifying zope itself are - customize all pages which need authentication to check for https://; in one of the relevant REQUEST attributes and do a redirect if not. - use apache with some magic to trigger redirection if it encounters authentication headers in the request. - use apache with some rewrite magic trigger redirection when a substring like manage is found in the request. These alternatives are neither elegant, nor really secure. I would agree the first two aren't sane, the third however is as good and as secure as you're going to get. Techniques for accomplishing it have been discussed on the zope list before and are undoubtedly in the archives. The mods you've posted with respect to guarding the WWW-Authenticate header aren't likely to work, and certainly wouldn't be flexible enough to allow, for example, mandating SSL usage for all /manage* requests while allowing clear-text basic auth for other restricted areas. Apache rewrite rules OTOH are flexible enough to allow this. I'm unclear as to why you consider it to be insecure, care to elaborate? The third alternative is indeed secure compared to the other two, in that it prevents plaintext credentials from going over the wire - as long as you remember to use always names like manage*. It's factually more insecure than my idea in that even ZMI's methods can be accessed with mangled names (e.g. http://server/manage/index_html). It's cumbersome because newly installed products always have to be checked for the method names. It's shaky, because if your filtering is too broad, better don't give the corporate management profile page an intuive id ;). And it's clearly worse performance wise for the typical use case, because you now get a load of rewrite stuff for any URI which has to be processed. All these complications and administrative burdens alone lead in effect to insecurity. The example code I posted was more or less to illustrate my intention, if I'd know where to implement such a hook, I'd probably try to make it more flexible. Make it dependend from a startup flag, and check for a magic attribute in the acquisition chain perhaps, which prevents the redirect. Also allow for redirects to a different host. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] 2.6.1 Plan?
Ross J. Reedstrom wrote: It what world do you live, and can I move there? Every large open source project I've particpated in or kept track of has had this problem - it's _really hard_ to turn down cool new patches just because your supposed to be in feature freeze, trying to get a stable release out. What do _you_ think 'normal open source practice' is? FWIW, see as an example http://developer.kde.org/development-versions/kde-3.0-release-plan.html and/or http://developer.kde.org/development-versions/kde-3.2-features.html Seems to work quite well for them. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] form variables and **kw
Reposting to zope-dev because no answers on the zope list. Hi all, I have some questions. Say I have a external method/product method return_vars which I call from a form: def return_vars(self, var=None, **kw): return var: %s, kw: %s % (var,kw) Is it correct that any passed form variable besides var will get lost, i.e. that ZPublisher will _not_ marshall the other variables into the method call? If so, why? Is this a python limitation? I played around with co_varnames and python doesn't seem to offer a possibility to recognize **kw as something special. Where does this marshalling happen, in ZPublisher/mapply.py? TIA, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] form variables and **kw
Toby Dickenson wrote: On Wednesday 02 Oct 2002 9:31 am, Oliver Bleutgen wrote: i.e. that ZPublisher will _not_ marshall the other variables into the method call? Would you really want all of them? All those that come from query string? http headers? cookies? environment variables? Only form variables. But you're right, this would be inconsistent. You can get sane access to all of these through the REQUEST parameter. Im sure you know that. Yes, I know. The problem at hand was the invokeFactory method from the CMF (1.1), which only has id as a parameter, but not title, preventing me from using it directly with a form which also wants to set the title. My workaround is to use a proxy method which has title as a named parameter. Thanks, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] find unused objects: hopefully the last misunderstanding...:o)
R. David Murray wrote: On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote: Consider a tab for methods... which allows to parse them and produces a sortable list of links to the other referenced methods... Good luck grin. You might manage a Quick and Dirty implementation, but to guarantee you've not missed anything you pretty much have to run the site as a program, which leads you to the classic computer science halting problem, I think. And that still doesn't address the question of external references. By the way, new question: Is this the correct mailing list for such suggestions? If not, which one is it? For the original has anyone implemented question, probably 'zope'. For a discussion of how to implement this (or rather the effective impossiblity of implementing this reliably) this is probably the appropriate place. Ok, quick and probably dumb idea how one could write a ZLinkBot. If there is a central part in zope (ZPublisher?) which always runs when methods/scripts/etc are called, one could patch it to also log the path of the object which is called (the physical path!). Then just use a web spider which crawls the whole site, and after that compare the list which has been produced by the method above to the list of objects in your ZODB. Everything which hasn't been touched is an orphan. Could ZPublisher.Publish.call_object() be that central piece of code? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
Christopher N. Deckard wrote: Oh, and back on the original topic, does anyone know for sure if the browsers actually send something to the server when stop is pressed? Yes, it sends a RST packet. It ends the tcp-connection. That's why I think throwing an exception when something tries to output data to be served to such a connection is the right thing to do (while it may be not so easy to implement with zope, I don't know). Since the connection is gone, there's no point in accumulating data to be sent back. Tim Hoffman [EMAIL PROTECTED] wrote: Hi Just my 2c worth, I wouldn't want this to be a blanket approach if it where ever implemented. If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-) or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.) I don't know why these examples should be an argument against implementing a saner (just IMO!) policy into zope regarding connection resets. If something like I described would be implemented into zope, it surely should be possible to start an extra thread for doing the stuff you give as an example, or - less desireable IMO - to ignore the connection reset. If this were implemented with an exeption, you just had to catch it and you're done. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
Chris Withers wrote: I know I'm late in on this thread, but I thought I'd throw in my views. This is very nice, it seemed like nobody was interested in that. I'd like to see the REQUEST be flat plain aborted when someone hits the stop button or the connection dies. Yes, that would be the optimal solution. Unfortunately it seems to be (nearly) impossible to do. I don't is the is context.REQUEST.RESPONSE.isClientConnected() really working. How would I plug this in an expensive SQL SELECT/JOIN? Why do we need this extra programming overhead? The problem seems to be that when you started the sql query, there's not much zope could do, even if it knew that the stop button was pressed - if I understand Chris correctly, that. I'm all for isClientConnected, because it gives you at least the possiblity to find out about aborted connections. This could come in handy _before_ starting long sql-queries/other expensive tasks. But, like you, I think zope should be a little bit more clever out-of-the-box at it is now. As for the long running administrative tasks, I actually see the ability to bugger off and leave them running as an extremely bad thing. Say I hit 'pack' on a big fat ZODB. I then go somewhere else. How do I now tell when its done? The only was would be to go and look at 'top' and guess which python thread is doing the pack and wait till its CPU usage drops to zero. That's pretty ropey ;-) For the same reason, I hate ZEO's pack's possibility of returning before a pack is finished. If you do a pack, I really think you should wait for the browser to return. If the browser times out, then use something like wget. If I hit 'stop', the pack should abort. Hmm, can a pack always safely rolled back? As a parting example, what happens if I accidentally start a pack? How can I stop it? ;-) Hit the power button on the server ;-))). I did do some diggin about mod_perl and java meanwhile, maybe zope can learn something here. Mod_perl also seems _not_ to stop a long running script if this script doesn't try to write to the RESPONSE (or whatever they call it). The perl test script I posted does write output, and this causes it to stop. If I try a script with no output, it never gets stopped. Java servlets also seem only to get stopped automatically if they try to write into the RESPONSE stream of a closed connection. Buffering aside, if you try to output something in a servlet and the connection is closed, you get an exception. Im my uninformed opinion, Zope should do the same. Is this possible? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
Steve Alexander wrote: Oliver Bleutgen wrote: Although Zope has a response stream method of sending information back to the client, most things in Zope don't use it. Instead, the response information is aggregated, converted into a string, and then sent back all at once at the sucessful completion of the transaction. Well, then it may be difficult to get zope to behave like the other systems, right? These other systems you mention are using the availability of a response stream as a surrogate for RESPONSE.isClientConnected(). I'd rather have an explicit RESPONSE.isClientConnected(). This is not correct. The systems I mentioned do also have the possibility to check if the client is still connected, it's just that they additionally prevent writing to a response which will never get delivered. This is quite reasonable IMO. Although, it would make sense to raise an exception if someone tried to write to the Zope response stream, in the rare cases when this does happen. I know we are talking about extreme cases here. But the behavior of java and mod_perl may prevent the whole system from falling over on a loaded server. This is made worse by the relative small number of threads which are running on a stock zope. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: Browser Stop Button and Zope REQUESTs
Toby Dickenson wrote: On Wed, 2002-08-28 at 07:49, Chris Withers wrote: I'd like to see the REQUEST be flat plain aborted when someone hits the stop button or the connection dies. Thats probably impossible if there is an HTTP proxy between your browser and zope. Why? It seems logical for a proxy to also reset the connection to the backend server when he looses the connection to the client. I haven't verified this, though. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Last-modified and bobobase_modification_time
Wei He wrote: On Mon, 17 Jun 2002, Dieter Maurer wrote: R. David Murray writes: ... Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a [EMAIL PROTECTED] question. The second is the question of whether or not that is the right behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. Think about it. It is very difficult. In order to determine the accurate modification time, you need to render the template (as it is non-trivial to determine the set of objects the rendering depends on without actually doing the rendering). Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. Thus, you cannot have accurate modified headers for HEAD requests. Moreover, usually HEAD requests do not pass the necessary parameters for template rendering. Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic. HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Last-modified and bobobase_modification_time
Toby Dickenson wrote: Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. On Tuesday 18 Jun 2002 10:26 am, Wei He wrote: I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea? Yes, I think that makes sense. A while ago the list discussed changing Zope's security declarations to add a way to specify whether a published method has significant side-effects. Side-effect-free methods can have HEAD and GET handled identically. Methods declared to have side-effects can only be accessed though a POST. I guess GET or HEAD on such methods would result in a 405 error (Method Not Allowed) (Such a change would also go a long way to reducing the scope of client-side-trojan vulnerabilities.) Yes, and sadly this discussion died a miserable death. This is the point I omitted in my other reply. Dieter presumtion that GET can have sideeffect in zope, while right, shows exactly the problem with not following the RFC recommendations. I know that it is nearly impossible to follow this strictly - as far as I see it wouldn't even allow showing visitor stats on a frontpage - but zope should at least offer some infrastructure to handle this. And it absolutly should be stricter in it's management interfaces and such. To be clear, the RFC says: HEAD SHOULD NOT have sideffects. GET SHOULD NOT have sideffects. HEAD SHOULD return the same http-headers as GET. So none of the discussed changes would make zope violate the RFC, as it doesn't really require the above, it just recommends. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] RFC 2616, side effects, and idempotence (was: Last-Modified....)
R. David Murray wrote: On Tue, 18 Jun 2002, Oliver Bleutgen wrote: Toby Dickenson wrote: Rendering may produce side effects. But HEAD requests are required by HTTP not to have side effects. RFC 2616 section 9.4 states that HEAD is identical to GET in this respect, and both should have no side effects. First, your quoting is wrong, I didn't write that - talk about precisionist *g*. This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology grin. The RFC does *NOT* say that GET and HEAD must have no side effects. That is just the simplist implementation of what it *dees* say, which is that GET and HEAD must be idempotent. When Tim (I think it was) mentioned this in the first round of this disucssion, I had to look it up even though it is a good math term and I was a math major. This doesn't cover everything. First, you're right, the RFC indeed doesn't say MUST anywhere concerning the areas we are talking about. This is important. Zope does not violate the RFC. But, the RFC introduces two, let's say attributes to methods. One is idempotent, which is described in 9.1.2 which you righlty refer to. But, there's also the attribute safe, which is described in 9.1.1: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. Which is IMO exactly what we were talking about in that thread. So it seems to me that some of the concern I have seen in Zope code with avoiding write on read, where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. There may well be other reasons to wish to avoid idempotent write-on-read (although I haven't thought of any yet), but RFC 2616 isn't one of them. Perhaps it is. I don't know the areas of the code where you have seen that, but it might be inspired not by the problem of idempotence, but of safeness PS: somehow, I don't think the spec writers thought much about hit counters... Lol, I think so too. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] PHP vs Zope cost benefit
Jason Spisak wrote:
You might remember me, I've been a big Zope fan since ZTables,
and have recently been asked Why Zope?. The project is
commited to PostgreSQL and leaning toward PHP. Here's the
project requirements for a softwre company:
Hardware Compatability List
Software Compatability List
Store/ECommerce
User tracking and services like
Pay for downloads
Upgrades if they have a serial number paid up
Billing/Invoicing for corporate accounts
Inventory tracking
CRM/Sales functions
They don't see that Zope's built in security machinery would
beat something home brewed for what they expect to need it for.
Plus the over head of running Zope instances is greater than
PHP scripts.
What are the arguments for Zope in this context?
Transaction Safety?
When reading your requirements that was the first thing coming into my
mind. I don't know how php does this, so I went to google and found
http://www.phpbuilder.com/columns/linuxjournal29.php3
Below is one snippet, notice all the ugly //check for errors and
//abort transaction. If someone knows where I misinterpret something
or how php solves this, corrections welcome.
But wouldn't it be nice if we had an application server which would take
care of all this for us?
Oh, wait ... ;-)
cheers,
oliver
function cart_new() {
//make the database connection handle available
global $conn,$customer_id,$feedback;
//start a transaction
query(BEGIN WORK);
//query postgres for the next value in our sequence
$res=query(SELECT nextval('seq_customer_id'));
//check for errors
if (!$res || pg_numrows($res)1) {
$feedback .= pg_errormessage($conn);
$feedback .= ' Error - Database didn\'t return next value ';
query(ROLLBACK);
return false;
} else {
//set that value in a local var
$customer_id=pg_result($res,0,0);
//register the id with PHP4
session_register('customer_id');
//insert the new customer row
$res=query(INSERT INTO customers (customer_id) VALUES
('$customer_id'));
//check for errors
if (!$res || pg_cmdtuples($res)1) {
$feedback .= pg_errormessage($conn);
$feedback .= ' Error - couldn\'t insert new customer row ';
query(ROLLBACK);
return false;
} else {
//commit this transaction
query(COMMIT);
return true;
}
}
}
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Florent Guillaume wrote: Oliver Bleutgen [EMAIL PROTECTED] wrote: The issue of client side trojan recently came to my mind again. [..] I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. I like the idea of trying to secure that kind of things a lot. Unfortunately, considering how trivial it is for Javascript code to do a POST programmatically, I don't see how that proposal would actually help. Although I repeat myself, implementing this proposal would give me a lot of options to prevent myself from this kind of attack, completely or partially. - In Internet Explorer I can disable javascript. (problem solved) - In Internet Explorer I use the zone restrictions (prevents attacks from untrusted servers) - I can do the same in mozilla - additionally, in mozilla I can just disable form submitting in javascript, with something like (this is surely wrong) user_pref(capability.policy.default.HTMLFormElement.submit, noAccess); Put this your prefs.js file and you are done. Really, it _would_ help. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Jeffrey P Shell wrote: I have to now admit to not having seen the proposal, I've just been following along here and struggling to capture the meaning of idempotent as it applies to Zope security, but I *think* I'm starting to grok it. Since a search for idempotent on zope.org yields no results, I'm assuming that your proposal isn't up there (or the catalog is up to its old charms ;) Jeffrey, idempotence is mentioned about in the http/1.1 rfc, which says Methods may also have the property of idempotence in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. There's another quote from the rfc in my posting which started this thread. The question is, to put it bluntly, if e.g. something img src=http://yourserver/manage_delObjects?ids:list=an_object; anywhere on any page you might visit should be able to do what it does now, if you happen to be authorized at yourserver with enough priviledges. The fix would be to not accept GET requests for certain methods. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
First, Toby, thanks for that proposal, it's indeed far more elegant than the mess I had in mind. Casey Duncan wrote: Toby Dickenson wrote: [snip] 4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it should still allow dtml-var someNonIdempotentMethod() Ahhh! How do you propose to do that? I see a lot of bruised foreheads resulting from this... Maybe we don't need that point, because methods declared nonIdemPotent (maybe we should call it disallowGET?) would fail anyway if they had been passed the original REQUEST. How many problems would this cause. [snip] c. It affects code that uses dtml-var someNonIdempotentMethod to call a method with no parameters. I have no idea how common that would be. Likely very common. Are you sure? But anyway, this checking also could be disabled (or - upgrade path friendlier - enabled) by a command line switch (or a config file). Anybody could check their own Sites/Products just by enabling the checking. I for one would consider it a bug if my application failed with a zope behaving like the authors of the http rfc are recommending. On balance, I think it might be worth building a prototype. Best of luck to you. My personal opinion is that it might be ugly and potentially cause problems with the upgrade path now, it will get even worse the more features zope gets. I suspect the question of the request method will get more important, as more and more protocols use HTTP as a transport. So perhaps at least the first point of toby's proposal - or something functionally equivalent - could be implemented (adding this method to ClassSecurityInfo), which wouldn't hurt anyone, but give application writers the chance to use this feature. cheers, olive ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Casey Duncan wrote: [SNIP] Also, are we talking about only fixing the action on GET for the ZMI or for all Zope apps? If the answer is Just the ZMI then we are talking about doing something that has not been done before: Making the ZMI different from all other Zope apps. If the answer is All Zope Apps then I fear you have just broken every Zope app I have ever seen 8^). But as I read here it is planned for Zope3 to change the ZMI anyway, which will at least break the lookfeel of any zope app which integrates with the ZMI, and therefore will make the ZMI different from zope apps. I guess there might be more breakage. So sometime in the future application writers will have to upgrade their apps anyway. And Tob As I understand Toby's proposal, you have to explicitly declare if your method can only be invoked via POST, not the other way around. So it's optional for the applications, as long as they don't pass the GET-polluted REQUEST to ZMI methods. If I were to implement this, a very simple approach seems attractive: Lock the ZODB on GET requests so that no transactions can be committed. However, I'm not sure I want to go there. No, I would like the application writer to be able to write unsafe methods. It's also quite a mess today (at least IMO) how version cookies are capable of messing around with the ZODB in suprising and (IMO) unwanted ways. I may have some strong feelings about this security stuff, but it's not too hard to give a scenario where zope's promiscuity in this respect can have really ugly effects - and it doesn't need much imagination. With the implementation of Toby's proposal (barring the dtml-var thing, which isn't needed for that, as far as I see), one could at least be secure when javascript is disabled. Maybe browser writers one day will wake up and also follow the recommendations of the rfc, then zope will be there already. Ok, my knowledge of zope's innards stops quite before ZPublisher comes into play, not to talk about Zope 3, but I'm willing to offer help where it's possible. What can I do now? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Lennart Regebro wrote: From: Oliver Bleutgen [EMAIL PROTECTED] I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. Do you have any proposal for how to go about doing this? Well, I don't see how one could do that systematically, by what I mean doing it on a single point and be done for all methods. I am not too intimate with the deeper innards of zope (ZPublisher ZODB etc.), but I suspect it would be nearly impossible to decide, in a sane way, what would constitute an active (i.e. destructive or constructve) method. A method that causes a write to the ZODB? No, that wouldn't fly. I was thinking more of something like adding the checks individually to each method in stock zope for which it is appropriate. Brian is of course right in his other mail by stating that this might and will break custom products which use the wrong method, but I wouldn't call a global s/method='GET'/method='POST'/g ( SCNR ;-) ) a code audit. It might be also made customizable via a command line switch to z2.py in the beginning, with default to off. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...
Jim Washington wrote:
2. If we want to get fancy about allowing authentication using that ip
address like naked ZServers can do,
In lib/python/AccessControl/User.py, around line 1116,
change
if request.has_key('REMOTE_ADDR'):
addr=request['REMOTE_ADDR']
to
if request.has_key('HTTP_X_FORWARDED_FOR'):
addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
addr=request['REMOTE_ADDR']
I do not believe this does anything to authentication that is not
possible now regarding spoofed ip addresses, so probably not a major
security headache.
Correct me if I'm wrong, but this IMO makes spoofing against a naked
ZServer a childs play. It's just adding a custom header to the request.
I also doubt that every reverse proxy overwrites this header, so
zservers behind a proxy might also be hit.
TCP spoofing OTOH is far more complicated, if (does it?) zope turns off
the source routing option when replying, if present. IMO something like
cracking a router or predicting sequence numbers is another level from
adding a custom http-header.
cheers,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Lennart Regebro wrote:
From: Oliver Bleutgen [EMAIL PROTECTED]
I was thinking more of something like adding the checks individually to
each method in stock zope for which it is appropriate.
Brian is of course right in his other mail by stating that this might
and will break custom products which use the wrong method, but I
wouldn't call a global s/method='GET'/method='POST'/g ( SCNR ;-) ) a
code audit. It might be also made customizable via a command line switch
to z2.py in the beginning, with default to off.
This would be a huge task. My gut feeling is that it is a lot of work for
very little benefit, although I don't really have any arguments to back that
up with.
Would it really be a huge task? Wouldn't we just have to find all
methods which are callable through the web and add two maybe three
identical lines of code right at the beginning?
Something like (sorry for the wrapping)
if REQUEST and REQUEST.has_key('REQUEST_METHOD') and
REQUEST['REQUEST_METHOD'] != 'POST':
raise APPROPRIATE_ERROR, Appropriate message
cheers,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
[Zope-dev] [RFClet]: What about the request method and the client side trojan?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] OpenSSH configuration between ZEO clients storage server
Adam Manock wrote: Yes. The best solution would be for the ZEO protocol to support auth and crypto natively... The next best solution (while you wait) is to use CIPE ;-) As far as I understand it, even regular TCP port forwarding is TCP over TCP and suffers from the unreliable carrier assumption causing excess (eg retransmit) traffic over a reliable channel. Out of interest, could you elaborate that? I assume you mean port forwarding (without the TCP), which, AFAIK, just is a rewriting of some IP/UDP header information and some, uhm, forwarding. I am not aware of any encapsulation taking place. I quite sure that this isn't the case, because, after all, we can talk to a normal tcp/udp server on the ipaddress:port which we forward to. We can also port forward udp-traffic. SSL then adds another layer between transport and application, but it explicitly needs a reliable transport protocol underneath (e.g. TCP). Consider: host --TCP-- local interface --TCP tunnel-- local interface --TCP-- host host --TCP-- virtual loopback interface --TCP-- host In this common port forwarding scenario, the SSH or SSL tunnel creates a virtual single loopback interface that the two hosts use to talk to each other, using TCP. The transport that joins these two physical interfaces to create one virtual loopback interface is also TCP. Therefore it's TCP over TCP No, it isn't. You can use something like stunnel to https-enable non-https capable http-clients, stunnel -c -d 80 -r ssl-server:443 now go to http://localhost Try it, it's fun ;-). cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Memory Leak Problem
Toby Dickenson wrote: On Tue, 12 Mar 2002 18:38:16 +0100, Oliver Bleutgen [EMAIL PROTECTED] wrote: Acquisition.ImplicitAcquirerWrapper: 42442 That class is used to glue together acquisition content chains. Being top of the list indicates that you have been leaking an acquisition context chain. That doesnt mean that the bug relates to acquisition; acquisition just means that the leak is more severe than otherwise (because it keeps the whole context chain around). OFS.DTMLMethod.DTMLMethod: 3989 42442/3989 = 10.6. That indicates that you are leaking an acquisition chain of roughly 10 objects. ZPublisher.HTTPRequest.HTTPRequest: 3941 ZServer.HTTPResponse.ZServerHTTPResponse: 3934 ZPublisher.BaseRequest.RequestContainer: 3931 AccessControl.DTML.TemplateDict: 3930 The numbers for those objects are all roughly 3900. These objects are the ones referenced by that acquisition chain. I recommend you look further down that list, until you find a number that is much less than 3900. All of the objects above that mark are pieces of the jigsaw puzzle that will tell you *what* is being leaked. Thats where I would start meditating to work out *how* its being leaked. Ah, thanks for the nice explanation, Toby. I don't want to abuse your or others time too much, but since this might be interesting in general too, I'll give some more data. To be clear, I don't want to really trace down that leak, we live with it for nearly a year now, the server will be replaced soon, but I'm smelling some zen and my appetite is whet. - I did paste only the objects which have such a high count (next one was approx 200). - This server (2.3.3) has no special products on it, just 2 Folderish ZClasses, which are heavily used (they construct the whole site). So, can we rule out that there's a bug in the zclasses machinery which is the cause for this? I.e. should there be some zclass related object in the above list otherwise? Is it right that in Zope 2.3.x (and others?) usage of dtml-var REQUEST.set(...) can lead to such leakage? Is there a description somewhere what the basic causes of such leakages are? I.e. only bugs in python c-code/zope c-code? Is there some text about what to not do in python product development to avoid introducing leakage? For example, on #zope someone pointed out to me that storing acquisition wrappers in the ZODB will lead to leakage. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Memory Leak Problem
One more question then I'll shut up ;-). Toby Dickenson wrote: Is there a description somewhere what the basic causes of such leakages are? I.e. only bugs in python c-code/zope c-code? No, its possible for a bug in through-the-web edited dtml to cause this. Waah, this is the first time I hear that. That means that even if zope/python would be bug-free, it's possible to write dtml that causes a leak? Is there a (non-esoteric) example for that? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Memory Leak Problem
Hi all, i have a little problem with my production server. The memory usage of the zope processes running on this server are growing up 100K a day upto 1MB a day. How can i track down the problem. [snip] Chris McDonough wrote: Finding memory leaks is an exercise in binary search. Isolate half of the Zope (and Product) code and find out if it leaks. If it doesn't, you know the problem is in the other half. ;-) Ad infinitum. I'm sorry this is the case, but it almost always boils down to this particular recipe of diagnostics. A question and one remark. Wouldn't staring at the refcounts in the debug panel also give some info? At least for selfmade products? Something like: Acquisition.ImplicitAcquirerWrapper: 42442 OFS.DTMLMethod.DTMLMethod: 3989 ZPublisher.HTTPRequest.HTTPRequest: 3941 ZServer.HTTPResponse.ZServerHTTPResponse: 3934 ZPublisher.BaseRequest.RequestContainer: 3931 AccessControl.DTML.TemplateDict: 3930 doesn't surely look too good, heh? ;-) Yes this is from a production server, which now get's restarted as it occupies 130MB (up from 15MB in 10 days). The remark, Andre, Chris has written a very nice product, called AutoLance which helps by monitoring zope's memory usage and restarting if a configurable threshold is reached. http://www.zope.org/Members/mcdonc/Products/AutoLance We use it on a production server. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: Zope vs. Cocoon
Very niceinteresting thread ... Stefano Mazzocchi wrote: Craeg K. Strong wrote: - Because of acquisition, you can add behavior to objects without changing their class definitions. Can you please elaborate more on this? I'm sure Craeg can and will, but there's IMO a very nice explanation about that from Dieter Maurer, take a look at http://www.handshake.de/~dieter/pyprojects/zope/book/chap3.html#acquisition cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Wild and crazzzzy idea: Hierarchial permissions
Lennart Regebro wrote: The list of permissions is getting quite long. It's the basic permissions of Zope, plus the ones for our CM system. And we haven't even integrated CMF with it (which we may or may not do in the future). To make things easier to find we have names all our permissions Easy something. I then got the idea that the permission list could be hierarchial or filtered or grouped or something. All permissions would have another setting to specify it group. That way the Zope base permissions could be grouped together into a Zope Base persmission group. We could group our in an Torped Easy Publisher permission group, and so on. Good idea or stupid? Well, for your use you could just hardcode some permission groups and include them in the dtml-file which resembles zopes security screen. A little bit javascript and selecting one of your groups would automagically be checked when you check one of your groups. What I'm missig more is flexibility for the Add object mechanism. The possibility to install products not globally, but locally for a folder and it's subfolders and some hierachical sorting of add type selectbox. Perhaps the tree could be (ab-)used to get a structure like + text product - DTML Document - DTML Method + Images, Files - Image - File + SQL Stuff - ZSQL Method - PoPy Database Connection - Search Interface etc To get back to the topic, perhaps your wishes and mine could be combined: A permissions group for edit text products which would automatically select the right permissions. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Repost to zope-dev: Best way to do links
Hi reposting to zope-dev because the zope-list didn't yield any answer (although it should belong there, I think). I am unsure how to achieve the following in a product: I have a folder with templates which shall be used to render articles. This folder will be the central repository of templates for all articles which find it in their acquisition path. Now, I want be able to dynamically assign (and change) templates for a given article, and if I edit one template it should reflect in all articles which are configured to use that template. In http://lists.zope.org/pipermail/zope-dev/2001-May/011187.html Shane Hathaway describe hardlinks, which seem to do what I need. i.e. I then just do t = template_folder.one_template self.template = t I looked at how ZSQL-methods solve that problem (usage of SQLConnections), and as far as I can see ZSQL-methods just store the id of the ZSQL connection and use that everytime they need to access the DB. Is that right and if so, why is it done that way? Doesn't give that a performance hit? And the last one: Will the above described method still allow import/export of these instances? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Stripogram or similar in core
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
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] RAMCacheManager and gzip
JanStiller T-Online wrote: Hi, Is it possible to marry the RAMCacheManager and gzip? I'm just working on a little shop and - for speed's sake - do 'ram-cache' the article-listings and push all the Zope-Content through mod_gzip. With this combination, I'm getting it 3x faster in Zope and 5x faster over the wire (normally 64k). That's great so far. But I don't see any sense in zipping cached content over and over, so I tried to zip the cached data in RAMCacheManager. [...] IMNSHO, mod_gzip does (can do) caching on its own (directives mod_gzip_keep_workfiles and mod_gzip_temp_dir), and perhaps it might work with mod_proxy in some intelligent way. Maybe you might want to check this first before doing too much work. Also be warned, there are certain kinds of documents which will make problems when served compressed, like PDFs. While you won't want to RAM-cached PDFs, it might occur that RAM-caching and compressing do conflict. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Versions (still)
So there I was in this discussion about Zope versioning (again) and there were two features requested that seemed perfectly reasonable at the time, - to have a list of all the objects changed by a version Sorry if this is obvious, but at least neither ZopeFind nor locked_in_version() seem to be mentioned anywhere in zope's (2.3.3) online docu, so I thought I might post it: dtml-in ZopeFind(PARENTS[-1],search_sub=1,obj_expr='locked_in_version()') LIfound dtml-var title_or_id html_quote in Version dtml-var locked_in_version /dtml-in - to be able to individually commit or discard changes in a version on a per object basis This is would be extremely useful for those times when you forget to check out of a version and accidentally lock the root folder (This happens quite a bit). Simple I thought, but ugh versions go all the way down to FileStorage and got into ZODB stuff I didnt understand. I would have thought having a little refactoring to give two more methods: getVersionContents and commitObject would be possible, but Im scratching my head at FileStorage now. Hehe, I feel with you, looking at how versions work takes one straight to Filestorage.commitVersion and some very low level code. Before I embark down this path is there an easier way? The question is if this is worth the effort, in the light of the new versioning discussion. The weaknesses of the current implementation of versioning puts some pressure to create something new IMO. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] IE and Zope MIME type handling
It is possible, as far as i know, to use the unix command file -bi filename and parse the returned result. It works very fine, but, unfortunatedly ;^)) just on Unix/Linux/*nix. Have read this on the [Zope] list and tested myself. This is not quite correct, http://sources.redhat.com/cygwin/ At least the cygwin UNIX for win environment includes file(1). So this should work on any plattform where zope works. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] zcatalog and versions
Thanks for the fast reply Casey. Casey Duncan wrote: On Thursday 27 September 2001 12:48 pm, Oliver Bleutgen allegedly wrote: Hi, I'm resending this to zope-dev because on zope nobody answered, it would be very nice if someone could step up with a small hint. Can somenone briefly explain what exactly gets locked in zope 2.3.3's catalog when it tries to index an object which is hold in a version? The whole catalog? Any Btree buckets (in the indexes) which get changed get locked, which can effectively lock out other changes to the catalog. This is a limitation of the way the indexes are implemented, for which, sadly, there is no easy fix. I found some answers which indicate that it has to do with the catalog when we see version lock errors where there shouldn't be any (from a naive POV). I would like to know how far reaching these problems are, because I'm currently rewriting an application, and I might be able to work around that. I would suggest that if any objects are reindexed in a version, that no cataloged objects should be reindexed in any other version until that version is saved. I hope I understand you correctly, but I'd say that if there's already a locked bucket, I've lost. There's no guarantee how long this particular version will stay uncommitted. I would also have to check anyhow whether there is a lock somewhere in the catalog's index. You could also get around that by deferring the indexing until the version is commited, but this will take some coding on your part. This seems easier - if I'm a little bit lax about when the indexing occurs. Like making the object only index/reindex/unindex itself if it's not in a version, and combining that with a nightly cronjob which reindexes all (non-versioned) documents. With some coding on your part you mean making Version.py more intelligent? Like instead of just doing commitVersion(s,'') doing the following: 1) search for objects which have been deleted in the version 2) search for objects which want to catalog themselves and are locked in version s 3) unindex the objects found in 1) 4) commit version 5) index/reindex objects found in 2) Where it's not clear to me how to prevent that 3) and 5) will not itself get versioned. Ultimately I think that ZCatalog should do this for you, or at least somehow let indexes have concurrent versioning (any volunteers?) I should say that I really don't grasp this ZODB voodoo, but I suspect that this will also be not too easy. AFAIK, the decision to write in a version (and in which) is taken deep down in zope's innards. I am thinking about writing a fishbowl proposal for ZCatalog upgrades sometime next month, and this is one potential problem areas to address there, especially as things like the CMF make it more ubiquitous If I don't misunderstand how versions work (not unlikely), it might be necessary in the end rather to improve versions than the zcatalog in order to remedy this specific problem. thanks again, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Vulnerability: attacking can get file list and directory
On Sunday 23 September 2001 08:24 pm, Joachim Werner allegedly wrote: Vulnerability: attacking can get file list and directory Tested on Win32 platform Example: telnet zopeserver 8080 PROPFIND / HTTP/1.0 enter enter enter list files and directory This tested on my site: security.instock.ru 8080 This one really seems to be the old WebDAV is not safe one. I guess it has been tackled already. You should be able to switch the file listing off for the Anonymous User in Zope 2.4.1 ... Joachim I totally agree. Tracebacks should not be visible to anonymous users! Although I would hesitate to call this a vulnerability, it ranks up there with the old ability to call objectIds by URL as anonymous. The less information that anonymous users can glean about the server, the better. From a non-technical, PR-wise point of view let me add that this type of vulnerability easily gets zope mentioned on lists like bugtraq. The perception is that these thing really are vulnerabilities. Proof: 17.9. A posting named Yet another path disclosure vulnerability targeted at oracle 9i appserver, and 21.9. RM Security Advisory: Xcache Path Disclosure Vulnerability both of which describe exactly the analogon to how zope handles things. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Vulnerability: attacking can get file list and directory
Hi shane, Oliver Bleutgen wrote: From a non-technical, PR-wise point of view let me add that this type of vulnerability easily gets zope mentioned on lists like bugtraq. The perception is that these thing really are vulnerabilities. You're right, a quick search on google for path disclosure vulnerability yields a lot of hits for lots of applications. It troubles me that people consider PDV to be important at all when the client-side trojan bug is still fully exploitable on all browsers including IE and Mozilla! (AFAIK) Client-side trojans, which can cause your browser to invisibly post a comment on a weblog, execute a financial transaction, or break into servers you maintain, are a major risk. I had put something about that theme at the client-side trojan wiki, put I'll repeat myself since you mentioned it ... Methinks the creators of the http/1.1 rfc were aware of the dangers we call client-side trojan and wrote the following: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. Zope really should not accept GET requests to dangerous manage_* (or other) methods, that would ensure it's at least compliant with the spirit of that rfc. If the user decides to use a browser which allows javascript to auto-submit forms and stuff, it's his choice. I have a feeling that other ideas like checking referer etc. are bound to fail after one or two generations of new browsers. We should have in mind that the same people who will design these browsers already had the bright idea of implementing auto-submitting of hidden forms. PDV just yields information you might give out anyway. But maybe we could deal with it anyway by writing an error.log instead of sending the traceback to the browser. What do you think? I fear it would make working with zope harder for unexperienced users. When working with apache/perl on linux, I always had a tail -f /var/log/httpd/error.log running in a terminal, but if you're solely working on windows without using the power of cygwin or other tools, this might get tedious. What I would like to see is a error product which can be freely configured to show more or less details depending on its context (i.e. user/role etc.) and able to optionally write to a log file. I know this is a lot of work and has its technical problems, but it's a nice imagination. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] New: Cross Site Scripting vulnerability
Aargh, I sent that first to [EMAIL PROTECTED] ... Hello message board. This is a message. SCRIPTmalicious code/SCRIPT This is the end of my message. I don't really see your point other than a carelessly implemented app may expose these kind of vulnerabilities. Python (and hence Zope) has a library for stripping out this sort of malicious HTML. Search for Strip-o-Gram or Squishdot on Zope.org for examples of how this can be used. umm chris, you're right, but this example http://www.zope.org/Documentation/SCRIPTalert(document.domain)/SCRIPT executes the script. I don't exactly see why/where but I feel this really shouldn't happen. As I see it, it's more a problem of zope's standard_error page, which constructs links to the classic zope site. I don't see a zope-specific bug here, too. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] ZPL and GPL licensing issues
as i said before, writing gpl code subclassing zope is a non-sense. even the author cannot, imho, redistribute its work with a plain gpl attached to it. the gpl says that if you link with gpl code *all* the code should be gpl or gpl-compatible (major os components like clibs, compilers, etc are an exception). so even the author cannot do that without licensing under gpl plus some exception (as a special exception you're allowed to link this code with zope or any other zope product distributed under the zpl.) see the (in)famous gpl vs. qt thread in the debian mailing lists for an in-depth analisys of this problem. To me this is the key point. If you GPL license a product (or other software) for Zope, you cannot subclass ZPL coded classes in your product without violating the GPL. This makes a strict GPL license nearly useless for Zope development and incompatible (license-wise) with Zope itself. What bugs me is when people point to the ZPL being the problem, it is the GPL that is the limiting factor IMEHO. -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- Either this is wrong, or I don't get it. The GPL talks just about _distribution_ of a product, or more precisely, about the rights of _others_ for distribution. I can distribute my products with any license I want, who should have a problem with that and what license may be violated? To cite the GPL: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. and Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. and (from the GPL-FAQ): Is the developer of a GPL-covered program bound by the GPL? Could the developer's actions ever be a violation of the GPL? Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a violation of the GPL. However, if the developer does something that would violate the GPL if done by someone else, the developer will surely lose moral standing in the community. I.e. I also can publish internet explorer specific javascript under the gpl (or vb-macros for that matter). and (also from the GPL-FAQ) I'm writing a Windows application with Microsoft Visual C++ and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ run-time library permitted under the GPL? Yes, because that run-time library normally accompanies the compiler you are using. The only problem I see is when someone (DC) wants to incorporate someone else's GPLed product together with zope, or when someone wants to modify someone elses GPLed zope product and distribute it. But I think even the second part isn't a problem, because the GPL says (under section 2, the viral part): These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. For me that means that as long as I distribute someone elses GPL'ed zope product without zope, it's ok. I guess that we all are in agreement that zope can be reasonably considered independent and separate work in themselves. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] ProxyPass and SiteAccess getting REMOTE_ADDR
From: "Chris Withers" [EMAIL PROTECTED] We're actually phasing this hack out in favour of a Virtual Host Monster which seems like a much cleaner solution... Sorry, Chris, VHM is irrelevent to this problem. If you want to know the original remote IP, you have two choices: 1. Use one of the Apache patches that have been posted. 2. Mangle it into URLs and extract it with an AccessRule. Neither one of these is really satisfactory at the moment, since medusa doesn't know either solution, and so z2.log doesn't get the proper IP addresses. I'm hoping that one of these days we can standardize on #1 and provide support in medusa. I don't get why it is necessary at all to use medusa's logging when using apache or squid etc. as a proxy. I for instance use apache to also serve content which isn't contained in the ZODB (large files etc.), and I want the logs/statistics to also contain information about these. Btw. with a small module it's even possible to log the usernames with apache, something medusa isn't capabable of afaik (as of zope version 2.3). cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
