Re: [Zope-dev] funky side-effects, possible bug in HTTPRequest.py

2003-06-20 Thread Oliver Bleutgen
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

2003-06-17 Thread Oliver Bleutgen
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

2003-06-16 Thread Oliver Bleutgen
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

2003-06-16 Thread Oliver Bleutgen
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?)

2003-06-10 Thread Oliver Bleutgen
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?

2003-06-10 Thread Oliver Bleutgen
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?)

2003-06-10 Thread Oliver Bleutgen
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?)

2003-06-10 Thread Oliver Bleutgen
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?)

2003-06-06 Thread Oliver Bleutgen
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?)

2003-06-06 Thread Oliver Bleutgen
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?)

2003-06-06 Thread Oliver Bleutgen
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?)

2003-06-06 Thread Oliver Bleutgen
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?

2003-06-05 Thread Oliver Bleutgen
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?

2003-06-05 Thread Oliver Bleutgen
[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?

2003-06-04 Thread Oliver Bleutgen
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?

2003-02-25 Thread Oliver Bleutgen
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?

2003-02-24 Thread Oliver Bleutgen
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?

2003-02-22 Thread Oliver Bleutgen
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?

2003-02-15 Thread Oliver Bleutgen
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

2003-02-09 Thread Oliver Bleutgen
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

2003-01-17 Thread Oliver Bleutgen
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

2003-01-16 Thread Oliver Bleutgen
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

2003-01-16 Thread Oliver Bleutgen
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

2003-01-16 Thread Oliver Bleutgen
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?

2002-10-29 Thread Oliver Bleutgen
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

2002-10-02 Thread Oliver Bleutgen

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

2002-10-02 Thread Oliver Bleutgen

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)

2002-08-30 Thread Oliver Bleutgen

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]

2002-08-29 Thread Oliver Bleutgen

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

2002-08-28 Thread Oliver Bleutgen

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

2002-08-28 Thread Oliver Bleutgen

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

2002-08-28 Thread Oliver Bleutgen

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-Coders] Re: [Zope-dev] DTML and REQUEST data changes aboutto be checked in

2002-08-09 Thread Oliver Bleutgen

Tres Seaver wrote:

 Martijn did add a knob to turn the feature off, via a new environment
 variable.  With a security vulnerability, we have to come up with some
 kind of balance between the need to propagate the fix as quickly as
 possible and the need (as you point out) not to disrupt production sites
 unduly.  I don't believe we can afford to wait a whole other release
 cycle for this fix;   Brian, Jim, and Martijn deemed the fix too
 pervasive to be bundled as a hotfix, which offers us little choice
 except to included it in current releases.
 
 Whithout the fix, virtually every Zope site in the world is vulnerable
 to URL-based cross-site scripting exploits.  For instance, any URL which
 contains invalid form variable marshalling can generate an error page
 which includes the erroneous value, unquoted.  E.g.:
 
 
URL:http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealert('Owned')%3C/script%3E

Yeah,

but why not fixing that instead?
I for one concur that it is a good thing to care for such stuff, but the 
way it is fixed might really lead to a lot of confusion, because it 
again introduces some magic which happens behind the users back.

As far as I understand the fix, I can imagine some use cases which might 
break without having been in danger at all. Someone please correct me if 
I'm wrong.

1. Sending mails with dtml-sendmail
If you send plaintext mails, suddendly you get html_quoted stuff which 
you never wanted. Having to debug this without knowing about the new 
feature will get people up in arms.

2. textarea ...dtml-var some_variable_contained_in_request/textarea

3. Any object which uses dtml to render content from the REQUEST not 
meant for being displayed in a browser.


Some people might use zope for things which have nothing to do with 
html, so they didn't care about cross-site scripting in the first place.

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

2002-06-18 Thread Oliver Bleutgen

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

2002-06-18 Thread Oliver Bleutgen

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....)

2002-06-18 Thread Oliver Bleutgen

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

2002-04-23 Thread Oliver Bleutgen

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?

2002-04-12 Thread Oliver Bleutgen

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?

2002-04-12 Thread Oliver Bleutgen

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?

2002-04-11 Thread Oliver Bleutgen

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?

2002-04-11 Thread Oliver Bleutgen

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?

2002-04-10 Thread Oliver Bleutgen

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...

2002-04-10 Thread Oliver Bleutgen

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?

2002-04-10 Thread Oliver Bleutgen

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?

2002-04-09 Thread Oliver Bleutgen

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

2002-03-28 Thread Oliver Bleutgen

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

2002-03-13 Thread Oliver Bleutgen

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

2002-03-13 Thread Oliver Bleutgen

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

2002-03-12 Thread Oliver Bleutgen

 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

2002-02-26 Thread Oliver Bleutgen

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

2001-11-22 Thread Oliver Bleutgen

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

2001-11-13 Thread Oliver Bleutgen

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

2001-11-12 Thread Oliver Bleutgen

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

2001-10-31 Thread Oliver Bleutgen

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)

2001-10-24 Thread Oliver Bleutgen

 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

2001-10-23 Thread Oliver Bleutgen

 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

2001-09-27 Thread Oliver Bleutgen

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

2001-09-24 Thread Oliver Bleutgen

 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

2001-09-24 Thread Oliver Bleutgen

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

2001-09-23 Thread Oliver Bleutgen

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

2001-06-21 Thread Oliver Bleutgen

 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

2001-02-13 Thread Oliver Bleutgen

 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 )