Re: [Zope-dev] Speaking of 2.6...

[Toby Dickenson]

On Wed, 17 Apr 2002 17:54:12 -0600, Jeffrey P Shell
<[EMAIL PROTECTED]> wrote:

>On 4/17/02 9:56 AM, "Gary Poster" <[EMAIL PROTECTED]> wrote:

>> If folks still want OrderedFolder (or, at least ordering capability) in the
>> core I'm still willing to help with that.

>For "add-to-the-core" functionality, I'll vote +0.5.  I wouldn't mind seeing
>it in the core, but I also like the idea someone mentioned of a sort of
>"expansion pack" of other good products that was well maintained alongside
>each core release.

I agree with both of these two points that Jeffrey made. It is a sore
omission from the core, but I cant see any place to hook the user
interface that doesnt amount to "bloat" for many folders that dont
need.

Does it make sense to include an ObjectManager.manage_reorderItems
method in the core, but leave the user interface to expansion pack
products ?




Toby Dickenson
[EMAIL PROTECTED]


___
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] Speaking of 2.6...

[Chris Withers]

Anthony Baxter wrote:
> 
> Anthony, who might have been spending too long in the bad places of SQL.

Maybe getting hooked back on the PHP too? I saw ya, that dodgy bloke in the
street, money changing hands...

*grinz*

Chris


___
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] Speaking of 2.6...

[Anthony Baxter]

> Chris - stay in the stone age, I hear they have fire there ;-)

mmm. fre pretty. 

"Page Templates burn, don't dey. Be a shame if somefing was to happen
to your nice shiny website".

Anthony, who might have been spending too long in the bad places of SQL.


___
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] Speaking of 2.6...

[Chris Withers]

Anthony Baxter wrote:
> 
> deliberately-trolling-for-ChrisW-ly yrs,

:-P

Chris - stay in the stone age, I hear they have fire there ;-)


___
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] Speaking of 2.6...

[Evan Simpson]

Lennart Regebro wrote:
 > There is an alternative, and that is to clean up the enhanced
 > enhanced virtual host monster we at Torped have done. It's based on
 > sfm@imemes enhanced VHM and just like VHF is makes it possible to
 > have standalone virtual hosting without strange apache magic. We
 > added an API to translate virtual to physical paths and back.

Just so you know, a limited version of the imeme enhancements is in the
Zope 2.5 VHM, and there is a standard REQUEST API consisting of
physicalPathToVirtualPath, physicalPathToURL, and physicalPathFromURL.

Cheers,

Evan @ 4-am



___
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] Speaking of 2.6...

[Anthony Baxter]

>>> Toby Dickenson wrote
> Do you remember what we had to type to achieve the equivalent of
> dtml-let, before dtml-let was introduced? That *was* horrible.

gee, I dunno...
 
has a sort of charm to it. 

sheesh, it's still not as ugly as ZPT.

deliberately-trolling-for-ChrisW-ly yrs,
Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>   
It's never too late to have a happy childhood.




___
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] Speaking of 2.6...

[Anthony Baxter]

>>> "Brian Lloyd" wrote
> We've been trying hard to adopt this bit of Zen. If you write 
> REQUEST.set, you can look at it and easily see what is happening. 
> Same with SESSION.set. 

The other reason why I made SESSION all shouty-caps in SQLSession[*]
is to make it _very_ obvious when it's being used. Storing stuff in 
a session is often one of the critical bits of a web request, so it's
important to me that it be clear and easy to see this.

Anthony

[*] I assume the standard Zope session stuff has adopted the SESSION
convention now? it wasn't in CST

-- 
Anthony Baxter <[EMAIL PROTECTED]>   
It's never too late to have a happy childhood.




___
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] Speaking of 2.6...

[Jeffrey P Shell]

On 4/17/02 9:56 AM, "Gary Poster" <[EMAIL PROTECTED]> wrote:

> On Wednesday 17 April 2002 11:48 am, Brian Lloyd wrote:
> 
>> Ok :) As far as "vetting" virtual host folder, my concerns
>> boil down to:
>> 
>>   a. dependency / requirement for ordered folder
>> 
>>   b. having yet another virtual host thing in the
>>  core will confuse people
>> 
>> ...
> 
> Hey Brian.  Thanks for your response.
> 
> All points understood and appreciated.
> 
> And I guess, then, that I'll choose not to make that commitment, since I'm
> looking forward to Zope3 these days anyway.
> 
> If folks still want OrderedFolder (or, at least ordering capability) in the
> core I'm still willing to help with that.

I'm a little surprised this hasn't come up for inclusion earlier.  When
showing a site to some top-management folk in a previous life, the question
that came up most often was "can we organize those links on the side so that
blablabla is first?".  One person would ask it, I'd respond with the "hmmm,
not easily - at least, not in time for our deployment date".  Then the next
person would come in late to the meeting, ask the same question, we'd laugh
and tell them the scenario - "to make admin easy, it's just listing the
documents in that folder that are public, using the API's already
available!".  They'd go OK.  The tour continued.  Another straggler comes
in, the loop repeated itself...  :).

For "add-to-the-core" functionality, I'll vote +0.5.  I wouldn't mind seeing
it in the core, but I also like the idea someone mentioned of a sort of
"expansion pack" of other good products that was well maintained alongside
each core release.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
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] Speaking of 2.6...

[Chris Withers]

Lennart Regebro wrote:
> 
> Yup. Therefore I think that the host monster shouldn't be included. VHF
> should supercede it.
> 
> If backwards compatibility is desired, add warning messages for usage and
> remove the VHM from the add box, but continue to include it in the code. :-)

Just as a passing comment from an extensive user of the normal virtual host
monster:

What you're suggesting sux badly, please leave it as it is!

cheers,

Chris


___
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] Speaking of 2.6...

[Dan L. Pierson]

--On Wednesday, April 17, 2002 11:48:12 AM -0400 Brian Lloyd 
<[EMAIL PROTECTED]> wrote:

> We've already learned the hard way that the existing SiteRoots
> and VirtualHostMonsters etc. confuse people. This is partly due
> to under-documentation, but it is also partly because of the
> "here, we'll give you several ways to do it!" approach.

True, but...

> If there are strong reasons for it to be in the core, then I
> suspect it would need to be sufficient to be the "official"
> VH solution and we'd want to deprecate the existing things.
> That means that it will need to be well documented, and we'll
> need to produce the needed deprecation docs, transition guides,
> etc.

Replacing VirtualHostMonster with VirtualHostFolder (via deprecation,
etc.) might be a good decision but please remember those of us
who need to use the SiteRoot/access rule combo to do more than
can be done with the higher level tools.  SiteRoots and access rules
are primitives that can not be replaced by higher level simple
tools.

Dan Pierson



___
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] Speaking of 2.6...

[Stefan H. Holek]

At 17.04.2002 10:57 -0400, Brian Lloyd wrote:

> >From the Zen of Python: "Explicit is better than implicit".
>
>We've been trying hard to adopt this bit of Zen. If you write
>REQUEST.set, you can look at it and easily see what is happening.
>Same with SESSION.set.
>
>If you're looking at  as a newbie to Zope, your
>first thought is probably "where exactly is this being set?".
>Who decided that REQUEST was a better place to implicitly set
>the variable? Why not the SESSION?

Agreed, in this light the set tag turns into a source of confusion.

How about a ,  pair then?

;-) ;-)


Stefan

PS: Only half joking as the dtml-set syntax is sweet, especially 'optional'...
PPS: I know ZPT ;-)

--
BLOWFISH n. - Preference for beef



___
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] Speaking of 2.6...

[Janko Hauser]

On Tue, 9 Apr 2002 13:47:49 -0400
"Brian Lloyd" <[EMAIL PROTECTED]> wrote:

> ...I sent out a note a while ago now trying to scare up 
> some ideas on how to vet the current list of 2.6 proposals 
> and get to a final "plan". I didn't get much (any?) response :(
> 

Hello Brian,

just to give some feedback and ask for guidance with the further
process. My college, Nils Kassube, has implemented the proposed
features, regarding an enhanced MailHost, namely the usage of
timeoutsocket in the SMTP-module and the archiving of outgoing mails.
We also asked the programmer of timeoutsocket for permission, although
the module has a BSD-license. He has no problem with the incorporation
of the module into the Zope2 code base.

Our current plan is to upload a patch to the collector, so other
people, specifically people with a server setup under windows can test
this and to send a note to Zope-Dev seeking for feedback. I have
checkin privileges and also signed the the necessary papers, so later
I can integrate the patch into the code base. 

Would it be enough to put a documentation in the proposal wiki and is
the proposal sufficient? Should we take other actions?

We would like to have this incorporated. Please take this mail as a
commitment notification :-).

Thanks for any answers,
with regards,

__Janko Hauser


-- 
i.A. Dr. Janko Hauser
Software Engineering
c o m . u n i t   G m b H
online-schmiede seit 1994

http://www.comunit.de/  mailto:[EMAIL PROTECTED]
Eiffestr. 598   20537 Hamburg | Germany
Fon 040 | 21 11 05 25   Fax  040 | 21 11 05 26




___
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] Speaking of 2.6...

[Gary Poster]

On Tuesday 16 April 2002 03:44 pm, Brian Lloyd wrote:
> > > ...I sent out a note a while ago now trying to scare up
> > > some ideas on how to vet the current list of 2.6 proposals
> > > and get to a final "plan". I didn't get much (any?) response :(

By the way, Brian, if I can with the remaining amount of time left, I'll do 
the work I volunteered to do.  However, perhaps I speak for others in that I 
look to you and ZC for leadership as to *whether* I should do the work.  I 
simply don't know how to vet the list, and I feel like you guys are the 
leaders.

I offered to help, and I meant it, but I feel you guys are the leaders for 
this, particularly for a release, for what seems to be obvious reasons.

So, at least to go back to basics and give you a practical answer to your 
question of ancient history, I have no idea how to vet the list.  If it is 
vetted and I am called on to do some work, then I'm happy to do it if my 
schedule still permits it by the time the decision is made.  This seems like 
another community initiative that fizzled: at least in my part that is so 
because I felt you guys should lead this, but I never got around to telling 
you so.  So, sorry. :-(  But better late than never, perhaps.

Maybe other folks disagree.

Thanks.

Gary


___
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] Speaking of 2.6...

[Brian Lloyd]

> > ...I sent out a note a while ago now trying to scare up 
> > some ideas on how to vet the current list of 2.6 proposals 
> > and get to a final "plan". I didn't get much (any?) response :(
> > 
> 
> I am, as the author of the dtml-set tag, of course willing to 
> commit to the
> implementation of this tag for 2.6
> 
> How about 'vetted' - It's set to N, when will I know if I should start
> coding?

Ivo - I don't have a problem with the spelling of this. I _do_ 
have a problem with the fact that it (your existing release) 
actually stores the variable in REQUEST. If it were to store them 
somewhere more appropriate in the DTML namespace stack, I'd be 
happy to OK it. 

We'd also need someone to commit to providing the extra docs 
for the help system and the dtml reference section of the 
online Zope book.


Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716  
Zope Corporation   http://www.zope.com 

 


___
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] Speaking of 2.6...

[Ivo van der Wijk]

On Tue, Apr 09, 2002 at 01:47:49PM -0400, Brian Lloyd wrote:
> ...I sent out a note a while ago now trying to scare up 
> some ideas on how to vet the current list of 2.6 proposals 
> and get to a final "plan". I didn't get much (any?) response :(
> 

I am, as the author of the dtml-set tag, of course willing to commit to the
implementation of this tag for 2.6

How about 'vetted' - It's set to N, when will I know if I should start
coding?

Cheers

Ivo

-- 
Drs. I.R. van der Wijk  -=-
Brouwersgracht 132  Amaze Internet Services V.O.F.
1013 HA Amsterdam, NL   -=-
Tel: +31-20-4688336   Linux/Web/Zope/SQL/MMBase
Fax: +31-20-4688337   Network Solutions
Web: http://www.amaze.nl/Consultancy
Email:   [EMAIL PROTECTED]   -=-


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

[Toby Dickenson]

On Wed, 10 Apr 2002 12:16:35 -0400, Jim Washington <[EMAIL PROTECTED]>
wrote:

>2.  If we want to get fancy about allowing authentication using that ip 
>address like naked ZServers can do,

>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']

There are lots of things that use REMOTE_ADDR, and I guess they should
*all* use the proxy supplied address rather than the address of the
proxy. It makes sense to me that we should *replace* REMOTE_ADDR with
HTTP_X_FORWARDED_FOR at the earliest opportunity. (and create a
X_FORWARDED_BY)

Have you considered this approach?


On Wed, 10 Apr 2002 18:59:38 +0200, Oliver Bleutgen <[EMAIL PROTECTED]>
wrote:

>Correct me if I'm wrong, but this IMO makes spoofing against a naked 
>ZServer a childs play.

Thats correct for a naked ZServer, or if behind a proxy which does not
sanitize the X-FORWARDED-FOR header. However it is safe if the request
comes from the right kind of proxy.

I think we need a new command line option to specify a list of IP
addresses which are trusted to run 'the right kind of proxy'. Zope
should only trust the X-FORWARDED-FOR header if the remote address is
one of its trusted proxies.

Pseudocode for handling this would be:

if request['REMOTE_ADDR'] in our_trusted_front_end_proxies:
request['HTTP_X_FORWARDED_BY'] = request['REMOTE_ADDR']
request['REMOTE_ADDR'] = request['HTTP_X_FORWARDED_FOR']




Toby Dickenson
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

[Jim Penny]

On Wed, Apr 10, 2002 at 06:59:38PM +0200, Oliver Bleutgen wrote:
> 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.

Note:  this is using another web server to front for zope.  It turns out
to be fairly safe -- I have used a variant for quite a while and did
quite a bit of testing.  For short hand, I am going to call the other web
server apache.  Apache presumably uses something like getpeername to
fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR.  If the remote
user attempts to spoof it (by using hidden variables, or other HTTP
based techniques), the Zope server interprets this is a list, rather
than the expected string.  This is easy to detect, and in fact, if you
fail to handle it, you will probably simply error out.

If the attacker is using TCP spoofing, there is really not much you can
do at an application level.

On the other hand, I am now conviced that this is not an intelligent
thing to do, not even for presentation.  You already have Apache in
front, so why not use rewriting rules to make the URL distinguishable.
In this way, you can use one of the BASE or URL variables to determine
how the person got in.  This gives you pretty much the same level of
control (especially if you are worried only about internal/external) as
using IP addresses, without modifying either Zope or Apache.

Jim Penny

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


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

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

Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

[Jim Washington]

Support for X-HTTPD-FORWARDED-FOR

Code for this is pretty simple:

modify 2 files, ZServer/medusa/http_server.py and 
lib/python/AccessControl/User.py

1.  To put the proxy-passed ip address in the zserver log,

Around line 269 in ZServer/medusa/http_server.py, add a method 
http_request::client_ip

def client_ip(self):
proxy_client = self.get_header('x-forwarded-for')
if proxy_client:
return proxy_client
else:
return self.channel.addr[0]

Then around line  294, change the statement that does logging to use the 
method.
self.channel.server.logger.log (
self.client_ip(),
' - %s [%s] "%s" %d %d "%s" "%s"\n' % (
name,
...

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.

Major possible problem I can think of:  I do not use ZEO, and have no 
idea what these changes might do there.  I do not have check-in 
privileges, and probably should not until I get a better clue of how cvs 
works :).

Anyway, here is the code FWIW.  Apologies that it is not a patch per se. 
 Now looking for a more clueful sponsor to take it from here to check-in 
(after vetting?)

-- Jim Washington

Brian Lloyd wrote:

>...I sent out a note a while ago now trying to scare up 
>some ideas on how to vet the current list of 2.6 proposals 
>and get to a final "plan". I didn't get much (any?) response :(
>
>For a couple of things that were ready to go and fairly non
>controversial (like Toby's unicode work), I put on the BDFL 
>hat and said "merge it!".
>
>But there are still a lot of things on the proposed features 
>that are undone, and some that are controversial enough that 
>we need to get to closure on them.
>
>I'll volunteer to convert the current proposed feature list 
>into a draft "plan", where the conversion boils down to 
>adding some columns to the table:
>
>Proposal - name and link to the proposal
>
>Resources - who is working on it
>
>Committed - Y/N whether the volunteers have committed to have
>the implementation and docs done by the first week
>in June. I'll fill in what I know has been committed
>to, people can update this (or let me know and I'll 
>do it), and anything that doesn't get a 'Y' in a 
>reasonably short time will be put in the cooler.
>
>Vetted - Y / N whether the community and / or the relevant BDFLs
> have come to some agreement on whether it *should* be 
> done. The list of items without a 'Y' will be our next 
> order of business. Getting to closure on those either 
> via the list, IRC, or whatever is the main block on the 
> critical path.
>
>Status - Complete or incomplete 
>
>
>I've taken a first stab at this. I've set the "committed" to 'Y' 
>for those things that I know I've gotten commitments for. For 
>those set to 'N', please let me know if you can commit to the 
>date (or change it yourself in the wiki).
>
>The updated plan is at:
>
>http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
>
>
>Once we get the commitments up to date, we can start wrangling 
>with the vetting...
>




___
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] Speaking of 2.6...

[Mario Valente]

At 15:12 10-04-2002 +0100, Toby Dickenson wrote:
>User X is designated as a manager of folder /Xfolder. In todays Zope
>/Xfolder is a secure environment He has no authority over objects
>outside that folder, thanks to aq_inContextOf
>
>Can he create links to objects outside that folder?
>

  No, he cant. To create a link (my hack...)  you first need to
 obtain the object reference (moniker) with a Copy operation
 so that you can then do a "Paste Ref." operation.


>Links would be pretty useless if not. 
>

  No they wouldnt.


>A common use case would be to
>create a link /XFolder/banner.gif to /stock_images/banners/mono.gif
>(for example).
>
>However if that is allowed, he now has management rights over that
>image object.
>
>I dont see how 'hard links' can possibly avoid this problem.
>

  Right. 

  But they would be useful to put an image in /Xfolder/images/
 and then be able to paste links to it into /Xfolder/layout1/ and
 /Xfolder/layout2/ and /Xfolder/Development without the need
 to create multiples instances of the same image or without
 coding multiple requests for that object.


  C U!

  -- MV











___
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] Speaking of 2.6...

[Mario Valente]

At 10:06 10-04-2002 -0400, Brian Lloyd wrote:
>What is wrong with leaving this as an add-on product? Why does 
>it _need_ to be a part of the core at all? Useful products are 
>useful, whether or not they "come with Zope", and there are 
>plenty of very useful products that don't come built in.
>

  I totally agree. Thats what I previously thought was the case: that
 your earlier comments were very much towards the "links" stuff
 being "Vetted" and that it should be released as a patch/product.

  C U!

  -- MV



___
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] Speaking of 2.6...

[Mario Valente]

At 14:38 09-04-2002 -0400, Brian Lloyd wrote:
>>   As in Unix, a hard link has different semantics from a soft link. I'm
>>  thinking of the "hard link" semantics. 
>
>Comparing it to Unix hard links is fine, but Unix doesn't 
>use Acquisition to handle security, so the comparison is 
>not apples-to-apples :) 
>

  No its not, agreed. But actually, when you create a hard
 link to an executable file and from within that executable
 request the path, you'll get different paths. Crappy way of
 doing security, but there's lots of people doing it :-)

  I guess you could call that acquisition :-)


>Security in particular is very concerned with *containment* 
>path (rather than just acquisition path) in order to prevent 
>"stealing" access through acquisition wrappers. Having objects 
>with more than one "place" may introduce much the same problem, 
>so we'll need to write up in detail the effects on the security 
>machinery or its application to domain objects (or if the security
>machinery does not need to change, we need to spell out why).
>

  I wouldnt mind doing this, but I think its out of my league

  C U!

  -- MV



___
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] Speaking of 2.6...

[Mario Valente]

At 01:30 10-04-2002 +0300, Myroslav Opyr wrote:
>Ok. Let's find out what we have and what we want. First of all we have 
>strict hierarchy in ZODB where each object appears only once in the 
>tree. Thus to access to an object it is only one way from root down to 
>an object through containers. 

>The idea is to allow user to specify several points of presence (pop) 
>for an object. 
>

  Precisely. My first hack solves this and I've been using it OK in
 production sites.

  But I didnt like the fact that an object "point of presence" in the
 Zope tree was identical in every instance. That leads to confusion.
  
  My second hack creates a ProxyObject class thus allowing for
 a different metatype and a different icon. This reduces confusion. And
 you can also provide a management tab with links to the "original" object
 "point of presence".

  I tried using Python 2.1 Proxy classes but Acquisition wasnt "proxiable"...

  C U!

  -- MV



___
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] Speaking of 2.6...

[Toby Dickenson]

On Wed, 10 Apr 2002 01:30:56 +0300, Myroslav Opyr
<[EMAIL PROTECTED]> wrote:

>Is Anonymous able to get out of the shared 
>object to secure environment?

User X is designated as a manager of folder /Xfolder. In todays Zope
/Xfolder is a secure environment He has no authority over objects
outside that folder, thanks to aq_inContextOf


Can he create links to objects outside that folder?

Links would be pretty useless if not. A common use case would be to
create a link /XFolder/banner.gif to /stock_images/banners/mono.gif
(for example).

However if that is allowed, he now has management rights over that
image object.

I dont see how 'hard links' can possibly avoid this problem.

Toby Dickenson
[EMAIL PROTECTED]


___
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] Speaking of 2.6...

[Brian Lloyd]

> The idea is to allow user to specify several points of presence (pop) 
> for an object. Does this break security? Probably yes, but in what case? 
> If an object from higly secure envionment appeared somewhere in 
> Anonymous zone, what then? Yes, Anonymous is able to alter object. But 
> there was reason for that!

Maybe - but maybe you just made the link without realizing 
the effect on security. That is one of the biggest conceptual 
problems here. Security behavior has to be as simple and 
understandable as possible for it to be useful. If people don't 
feel like they understand it, they will always have a nagging 
fear that they are vulnerable - and they will probably be right.

One could argue that we are already pushing the boundaries with 
the current security implementation, which is why the bar is so 
high for adding things to the core that potentially make things 
more complex yet.


> >Comparing it to Unix hard links is fine, but Unix doesn't 
> >use Acquisition to handle security, so the comparison is 
> >not apples-to-apples :) We need to spell out the exact semantics 
> >(*especially* wrt security, but also in terms of its effect on 
> >ZODB identity semantics, effects on undo, etc.)
> >
> Ok. I am not too well in English but I'll try to do my best. If it is 
> not hard for you give several words of explanation of "ZODB identity 
> semantics" and "effects on undo", not everything is clear for me.

Undo uses the "place" of an object as part of the criteria for 
deciding whether you can undo changes to it. If the meaning 
of "place" changes, undo behavior is likely to change. To use 
your earlier example, now Anonymous users might be able to undo 
changes made by a manager (in a different "place" on the "same" 
object). Is this acceptable? I don't know, but before we think 
about allowing changes like this into the core, the differences 
in behavior need to be spelled out in detail with specific examples.

Likewise with ZODB. What effects would links have on cache 
behavior (which are based on persistent identity)? On packing 
behavior? 


> Why we are not willing to allow such scenario? AFAIK there was and are a 
> lot of concernes refarding soft- and hardlinks in /tmp folder, with 
> sticky bit, etc... But they are usually solved with different means. 
> Yes, Zope and ZODB is much more complex. But why we have to limit 
> ourselves because something is difficult. 

I'm not trying to say that we shouldn't do something because 
it is difficult - just that in order to make changes like this 
we need to elaborate and understand all of the details and have 
a workable answer for all of the problems.


> Why not mark the feature as 
> experimental (red button, a lot of warnings, for instance) and make it 
> available to SuperManager only ;)

Because that's the textbook case for making it a Product :) We 
shouldn't be putting things in the core that come with flashing 
red warnings and can only be used by superusers.

What is wrong with leaving this as an add-on product? Why does 
it _need_ to be a part of the core at all? Useful products are 
useful, whether or not they "come with Zope", and there are 
plenty of very useful products that don't come built in.


Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716   
Zope Corporation   http://www.zope.com




___
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] Speaking of 2.6...

[Myroslav Opyr]

Brian Lloyd wrote:

>> Both me and Myroslav Opyr <[EMAIL PROTECTED]> are quite
>> commited to do the proposed "Object Links/References". Although
>> from the emails we exchanged with you, I would've guessed that
>> it was one of the "controversial enough" to be a Vetted item :-)
>>
>> Anyways I'm commited to do it. I do agree with your argument about
>> link semantics but, at least for me, a link/reference is a link, and the
>> semantics are perfectly defined i.e its not a RedirectObject.
>>
>> As in Unix, a hard link has different semantics from a soft link. I'm
>> thinking of the "hard link" semantics. 
>>
>I guess that what I was getting at is that the semantics 
>for this need to be spelled out in detail so that we can 
>make sure that they make sense before something like this 
>goes in.
>
Ok. Let's find out what we have and what we want. First of all we have 
strict hierarchy in ZODB where each object appears only once in the 
tree. Thus to access to an object it is only one way from root down to 
an object through containers. All security in Zope is based on that 
pattern. I am omitting Acquisition machinery to simplify (and I do not 
see it clearly in the context here).

The idea is to allow user to specify several points of presence (pop) 
for an object. Does this break security? Probably yes, but in what case? 
If an object from higly secure envionment appeared somewhere in 
Anonymous zone, what then? Yes, Anonymous is able to alter object. But 
there was reason for that! Is Anonymous able to get out of the shared 
object to secure environment? No in no simple way. Sure if an object was 
DTML and Anonymous placed trojan horse in the script and someone from 
secure environment executed the code then we run in a problem. But we 
can warn user! And we have a lot of "Restricted..." techniques, maybe 
one can be applied here?

>Comparing it to Unix hard links is fine, but Unix doesn't 
>use Acquisition to handle security, so the comparison is 
>not apples-to-apples :) We need to spell out the exact semantics 
>(*especially* wrt security, but also in terms of its effect on 
>ZODB identity semantics, effects on undo, etc.)
>
Ok. I am not too well in English but I'll try to do my best. If it is 
not hard for you give several words of explanation of "ZODB identity 
semantics" and "effects on undo", not everything is clear for me.

>Security in particular is very concerned with *containment* 
>path (rather than just acquisition path) in order to prevent 
>"stealing" access through acquisition wrappers. Having objects 
>with more than one "place" may introduce much the same problem, 
>so we'll need to write up in detail the effects on the security 
>machinery or its application to domain objects (or if the security
>machinery does not need to change, we need to spell out why).
>
Why we are not willing to allow such scenario? AFAIK there was and are a 
lot of concernes refarding soft- and hardlinks in /tmp folder, with 
sticky bit, etc... But they are usually solved with different means. 
Yes, Zope and ZODB is much more complex. But why we have to limit 
ourselves because something is difficult. Why not mark the feature as 
experimental (red button, a lot of warnings, for instance) and make it 
available to SuperManager only ;)

I'd be glad to get feedback, thanks,

Myroslav
-- 
Myroslav Opyr
zope.net.ua  ° Ukrainian Zope Hosting
e-mail: [EMAIL PROTECTED] 
cell: +380 50.3174578






___
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] Speaking of 2.6...

[Brian Lloyd]

>   Both me and Myroslav Opyr <[EMAIL PROTECTED]> are quite
>  commited to do the proposed "Object Links/References". Although
>  from the emails we exchanged with you, I would've guessed that
>  it was one of the "controversial enough" to be a Vetted item :-)
> 
>   Anyways I'm commited to do it. I do agree with your argument about
>  link semantics but, at least for me, a link/reference is a link, and the
>  semantics are perfectly defined i.e its not a RedirectObject.
> 
>   As in Unix, a hard link has different semantics from a soft link. I'm
>  thinking of the "hard link" semantics. 

I guess that what I was getting at is that the semantics 
for this need to be spelled out in detail so that we can 
make sure that they make sense before something like this 
goes in. 

Comparing it to Unix hard links is fine, but Unix doesn't 
use Acquisition to handle security, so the comparison is 
not apples-to-apples :) We need to spell out the exact semantics 
(*especially* wrt security, but also in terms of its effect on 
ZODB identity semantics, effects on undo, etc.)

Security in particular is very concerned with *containment* 
path (rather than just acquisition path) in order to prevent 
"stealing" access through acquisition wrappers. Having objects 
with more than one "place" may introduce much the same problem, 
so we'll need to write up in detail the effects on the security 
machinery or its application to domain objects (or if the security
machinery does not need to change, we need to spell out why).

Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716   
Zope Corporation   http://www.zope.com




___
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] Speaking of 2.6...

[Mario Valente]

At 13:47 09-04-2002 -0400, Brian Lloyd wrote:
>...I sent out a note a while ago now trying to scare up 
>some ideas on how to vet the current list of 2.6 proposals 
>and get to a final "plan". I didn't get much (any?) response :(
>

>But there are still a lot of things on the proposed features 
>that are undone, and some that are controversial enough that 
>we need to get to closure on them.
>

>Committed - Y/N whether the volunteers have committed to have
>the implementation and docs done by the first week

>Vetted - Y / N whether the community and / or the relevant BDFLs
> have come to some agreement on whether it *should* be 
> done. The list of items without a 'Y' will be our next 


  Hi:

  Both me and Myroslav Opyr <[EMAIL PROTECTED]> are quite
 commited to do the proposed "Object Links/References". Although
 from the emails we exchanged with you, I would've guessed that
 it was one of the "controversial enough" to be a Vetted item :-)

  Anyways I'm commited to do it. I do agree with your argument about
 link semantics but, at least for me, a link/reference is a link, and the
 semantics are perfectly defined i.e its not a RedirectObject.

  As in Unix, a hard link has different semantics from a soft link. I'm
 thinking of the "hard link" semantics. 

  C U!

  -- Mario Valente



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