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
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
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
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
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
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/
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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
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
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
[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
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
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:
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
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
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
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
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 ;-)
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
___
61 matches
Mail list logo
