[Zope-dev] can't put !--#BCODE -- in dtml

2002-04-11 Thread Yuan-Chen Cheng


hi,

Can't put !--#BCODE -- in dtml, but
!-- #BCODE -- is okay.

Is this correct.

Thank you very much.

Yuan-Chen Cheng

The traceback is here:

Unexpected tag, for tag !--#BCODE --, on line 8 of ttt

Traceback (innermost last):
File /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py, line
150, in publish_module
File /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py, line
114, in publish
File /home/ycheng/zope/zope/lib/python/Zope/__init__.py, line 158,
in zpublisher_exception_hook (Object: ttt) File
/home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py,
line 98, in publish File
/home/ycheng/zope/zope/lib/python/ZPublisher/mapply.py,
line 88, in mapply (Object: manage_edit) File
/home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py,
line 39, in call_object (Object: manage_edit) File
/home/ycheng/zope/zope/lib/python/OFS/DTMLDocument.py,
line 79, in manage_edit (Object: ttt) File
/home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
320, in munge (Object: ttt) File
/home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
line 340, in cook (Object: ttt) File
/home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
line 162, in parse (Object: ttt)
File /home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
line 58, in parse_error (Object: ttt)
Document Template Parse Error: (see above)




___
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 Toby Dickenson

On Wednesday 10 April 2002 5:07 pm, Brian Lloyd wrote:
  should not accept REQUESTs with REQUEST_METHOD GET.
 
 This is hard, hard, problem. While some good ideas have been
 proposed, there is not really a quick fix that doesn't have
 some downside that some group somewhere considers a
 showstopper :(

 I agree Olivers suggestion is not a total solution, but does it have a
 showstopper problem?

Only if you happen to have an application deployed and might
ever want to upgrade your Zope installation without having to
do a total code audit :^)


OK, heres a more specific proposal:

1. Add a method to ClassSecurityInfo declareNonIdempotent('methodName')

2. Add this declaration to ZMI methods which create, delete, or change 
content. (It also needs to get added to object constructors, but not the 
pre-constructor form. Im not sure exactly how to do that yet)

3. Change ZPublisher to not allow GET requests on non-idempotent methods. 
(This probably affects DAV and FTP too)

4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it 
should still allow dtml-var someNonIdempotentMethod()


How many problems would this cause.

a. It affects anywhere in the ZMI which currently use GET when they should be 
using POST. I suspect we would already know about such cases, because it 
would also cause problems when accessing the ZMI through a cache.

b. It affects any pages in other products that link to the ZMI using GET 
reqests. In a quick audit of my server logs I see I am doing this at least 
once; I have a script that uses a GET request to restart the server.

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.


On balance, I think it might be worth building a prototype.


___
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-11 Thread 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: [Zope-dev] can't put !--#BCODE -- in dtml

2002-04-11 Thread Matt Behrens

[For future reference, questions like this one should go to
[EMAIL PROTECTED]  [EMAIL PROTECTED] is for discussion of development of
Zope.  Replies/followups directed there.]

Yuan-Chen Cheng wrote:

 Can't put !--#BCODE -- in dtml, but
 !-- #BCODE -- is okay.

The !--# syntax is an old DTML syntax, so what is happening here is
that the DTML engine is trying to interpret the former as a DTML tag
named BCODE.


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

2002-04-11 Thread Jim Washington

Toby Dickenson wrote:

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?

Not yet, but I like the idea...  As with Oliver's reply, this I think 
would need some research.  I will be refining what I mean by support 
in the subject line shortly.



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

Excellent!  Except for command-line bloat.  With Matt Behrens's config 
proposal 
(http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration), 
this nevertheless could be workable.  Things are looking up.  Maybe. 
 U..., more research...

-- Jim Washington



___
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 Casey Duncan

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

 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.

 
 On balance, I think it might be worth building a prototype.

Best of luck to you.

-Casey





___
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] requestprofiler.py output width

2002-04-11 Thread Julián Muñoz

Hello,

requestprofiles.py is generating an output (on standard output) of
80columns width, and I don't know how to expand it.

At the begining I thought it was related with my xterm, but that's not the
case, the output is truncated to 80chars indepently if I use xterm, or if
I redirect the output to a file.



-- 

  __o
_ \_
   (_)/(_)

Saludos de Julián
EA4ACL
-.-

Foro Wireless Madrid
http://opennetworks.rg3.net



___
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] requestprofiler.py output width

2002-04-11 Thread Andreas Jung

--verbose
- Original Message -
From: Julián Muñoz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 11, 2002 10:38
Subject: [Zope-dev] requestprofiler.py output width


Hello,

requestprofiles.py is generating an output (on standard output) of
80columns width, and I don't know how to expand it.






___
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 Toby Dickenson

On Thursday 11 April 2002 4:39 pm, 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...

Really? dtml-var someNonIdempotentMethod only works with methods that take 
zero parameters (excluding self). The question is: how many zero parameter 
non-idempotent methods are there?

I have only been able to find one such method in the current Zope cvs, and I 
get similarly optimistic results in my products. 


Likely very common.

So far I have only been checking with crude greps, so I could be wrong. Any 
chance you could spend a couple of minutes looking for an example to share?



___
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 Casey Duncan

dtml-var foo is not even close to the equivilant of dtml-var foo()

The former uses mapply to comb the namespace for arguments and maps them 
to the callable and then calls it (if it is a callable, that is). IOW 
foo could have any number of arguments. The latter always calls foo with 
no argument.

My point is how do you disinguish dtml-var foo meaning Call foo 
passing everything from the namespace that maps to an arg from 
dtml-var foo meaning Call foo passing everything, but foo doesn't use 
anything from dtml-var foo Call foo and foo takes no arguments from 
dtml-var foo foo is not callable, so return the value of foo.

The most troublesome case is where foo accepts any number of arguments 
(such as a DTML method or ZPT or any other method with **kw), and you 
cannot know whether it changes objects or simply returns some string or 
something. I don't think it is helpful to assume that because a method 
takes arguments, it is dangerous. I can write destructive methods that 
take no arguments too.

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

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.

-Casey


Toby Dickenson wrote:
 On Thursday 11 April 2002 4:39 pm, 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...

 
 Really? dtml-var someNonIdempotentMethod only works with methods that take 
 zero parameters (excluding self). The question is: how many zero parameter 
 non-idempotent methods are there?
 
 I have only been able to find one such method in the current Zope cvs, and I 
 get similarly optimistic results in my products. 
 
 
 
Likely very common.

 
 So far I have only been checking with crude greps, so I could be wrong. Any 
 chance you could spend a couple of minutes looking for an example to share?
 
 




___
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 Lennart Regebro

From: Casey Duncan [EMAIL PROTECTED]
 My point is how do you disinguish dtml-var foo meaning Call foo
 passing everything from the namespace that maps to an arg from
 dtml-var foo meaning Call foo passing everything, but foo doesn't use
 anything from dtml-var foo Call foo and foo takes no arguments from
 dtml-var foo foo is not callable, so return the value of foo.

My point is: Why on earth would you do that? I don't see how preventing the
calling of dtml-var foo but allowing dtml-var foo() would have any
significant positive contribution, (except possibly clarity).

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

Well, I don't think I have ever used a GET to call a destructive parameter
in any application, but I can see that it is practical. What I have done
though, is to call it manually to do things when I have messed up. :-)

 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.

I'm sure I don't. :-) I just keep thinking there has to be a better way. I
haven't figured out what yet, though. :-)

Normally you would pop up a confirmation before taking destructive actions,
but I don't see how that is possible via a web interface. This is something
I really hate with the web. Every advancement that had been done in making
user interfaces consistent and usable was thrown out the window.

And I blame Netscape. The bastards.




___
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 Toby Dickenson

On Thursday 11 April 2002 5:16 pm, Casey Duncan wrote:

The most troublesome case is where foo accepts any number of arguments
(such as a DTML method or ZPT or any other method with **kw), and you
cannot know whether it changes objects or simply returns some string or
something.

Yes, that is a limitation of my proposal. It doesnt cover non-idempotent DTML 
and ZPT. (DTML and ZPT is idempotent by definition when used for presentation 
logic.)

I dont think that limitation is fatal.

 I don't think it is helpful to assume that because a method
takes arguments, it is dangerous. I can write destructive methods that
take no arguments too.

Sure you could. Lets assume you have, and have declared it non-idempotent as 
described in my proposal.

Firstly, you would not be calling it from DTML or ZPT if you were using those 
only for presentation logic. presentation logic by definition cant be 
destructive.

Anyway, even if you were writing a destructive DTML method, I bet you would 
write it as one of:

dtml-call my_destructive_method
dtml-call my_destructive_method()
dtml-var my_destructive_method()
dtml-in my_destructive_method()
dtml-with my_destructive_method()

but not:

dtml-var my_destructive_method
dtml-in my_destructive_method
dtml-with my_destructive_method

Those last three forms are today legal. My proposal would make them an error, 
but only because your new destrucive method has been declared non-idempotent.

I think thats an improvement, but only a slight one. It is much less 
important than Oliver's original proposal which was to control methods called 
by ZPublisher, not by DTML. I would be happy to go with a reduced proposal 
that leaves DTML unchanged, and made it an error to issue a GET request for 
http://host/path/my_destructive_method (but only because my_destrucive_method 
has been declared non-idempotent)


Also, are we talking about only fixing the action on GET for the ZMI
or for all Zope apps?

Much like when new style security declaration were introduced. Initially only 
ZMI had them, but new products could use them too.

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.

H. I wonder whether read-only transactions could be the basis for a 
ZODB optimisation...





___
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-11 Thread Toby Dickenson

On Thu, 11 Apr 2002 18:53:54 +0200, Oliver Bleutgen [EMAIL PROTECTED]
wrote:

With the implementation of Toby's proposal (barring the dtml-var thing, 
which isn't needed for that, as far as I see)

Correct. The dtml-var change only helps guard against a careless
dtml/zpt author reopening the same hole.


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] [RFClet]: What about the request method and theclient side trojan?

2002-04-11 Thread Jeffrey P Shell

On 4/11/02 7:55 AM, Toby Dickenson [EMAIL PROTECTED]
wrote:

 On Thursday 11 April 2002 4:39 pm, 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...
 
 Really? dtml-var someNonIdempotentMethod only works with methods that take
 zero parameters (excluding self). The question is: how many zero parameter
 non-idempotent methods are there?
 
 I have only been able to find one such method in the current Zope cvs, and I
 get similarly optimistic results in my products.

Then you're lucky.  Usually, any time I see dtml-var
someNonIdempotentMethod(), I immediately change it to the name lookup
call.  Don't blame me, I've been following this paradigm for years (since
before there were expr's in DTML).  I would hate to have to special case
those methods (which I use a lot, usually as accessors, ie:

def Summary(self):
return self.title + self._description
).

A powerful feature of classic (pre-expr) DTML was the fact that you could
just use a name, and you didn't have to worry about whether !--#var
Summary-- was a method or an attribute.  For people who have lots of DTML
and Python code based upon these assumptions, mass-breakage upon upgrading
would be a huge detractor against upgrading.  It's hard enough to move some
of our sites from Zope 2.3.3 to 2.5 or even 2.4.x.

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



[Zope-dev] REMINDER: Bug day tomorrow...

2002-04-11 Thread Brian Lloyd

Hi all - 

Just a quick reminder that our inaugural Bug Day is tomorrow 
Friday, April 12 9:00 am EST until... until we've all had 
enough. We'll be coordinating on the #zope-dev channel on 
irc.zope.org.

Some more info and general guidelines for bugdays are at:
http://dev.zope.org/CVS/BugDays

Hope to see you there!

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 )



[Zope-dev] Re: [Zope] setting default security permissions

2002-04-11 Thread Sidnei da Silva

I had the same problem a few weeks ago, and i posted my bug to the collector 
with a example class.

See there:
http://collector.zope.org/Zope/275

This friday, 9:00am EST there will be a BugDay on 
irc://irc.zope.org/#zope-dev

Description of BugDays here:
http://dev.zope.org/CVS/BugDays


I hope someone will be able to discuss this bug with me during the BugDay, 
and anyone with the same problem to be around and help.

[]'s

On Sab 06 Abr 2002 01:43, you wrote:
| I am building a python product. I am having trouble getting default
| security permissions to set.
| I am able to declare the permission properly, but the defaults dont work.
|
| I try the line
| security = ClassSecurityInfo()
| security.setPermissionDefault('View User Home',
|   ['Anonymous','Authenticated'])
| security.declareProtected('View User Home', 'home')
|
| The 'declareProtected' works, but the 'setPermissionDefault' has no effect
| on anything.
|
| I have no idea what else I need to be doing.
|
| Tom
|
|
|
|
| ___
| Zope maillist  -  [EMAIL PROTECTED]
| http://lists.zope.org/mailman/listinfo/zope
| **   No cross posts or HTML encoding!  **
| (Related lists -
|  http://lists.zope.org/mailman/listinfo/zope-announce
|  http://lists.zope.org/mailman/listinfo/zope-dev )

-- 
Sidnei da Silva (dreamcatcher) [EMAIL PROTECTED]
X3ng Web Technology http://www.x3ng.com.br
GNU/Linux user 257852
Debian GNU/Linux 3.0 (Sid) 2.4.19-pre6-ben0 ppc

But what we need to know is, do people want nasally-insertable computers?



___
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] RE: [Zope] setting default security permissions

2002-04-11 Thread Tom Cameron

After more experimenting, I discovered that a restart of the zope server
solved the problem.

Nice to know, but I dont really wish to restart zope everytime I make a
change. I am using Zope 2.5 and it appears that the refresh does not refresh
the default security permissions.

Tom

= -Original Message-
= From: Sidnei da Silva [mailto:[EMAIL PROTECTED]]
= Sent: Thursday, April 11, 2002 9:57 AM
= To: [EMAIL PROTECTED]; Zope-dev
= Cc: [EMAIL PROTECTED]
= Subject: Re: [Zope] setting default security permissions
=
=
= I had the same problem a few weeks ago, and i posted my bug to
= the collector
= with a example class.
=
= See there:
= http://collector.zope.org/Zope/275
=
= This friday, 9:00am EST there will be a BugDay on
= irc://irc.zope.org/#zope-dev
=
= Description of BugDays here:
= http://dev.zope.org/CVS/BugDays
=
=
= I hope someone will be able to discuss this bug with me during
= the BugDay,
= and anyone with the same problem to be around and help.
=
= []'s
=
= On Sab 06 Abr 2002 01:43, you wrote:
= | I am building a python product. I am having trouble getting default
= | security permissions to set.
= | I am able to declare the permission properly, but the defaults
= dont work.
= |
= | I try the line
= | security = ClassSecurityInfo()
= | security.setPermissionDefault('View User Home',
= |   ['Anonymous','Authenticated'])
= | security.declareProtected('View User Home', 'home')
= |
= | The 'declareProtected' works, but the 'setPermissionDefault'
= has no effect
= | on anything.
= |
= | I have no idea what else I need to be doing.
= |
= | Tom
= |
= |
= |
= |
= | ___
= | Zope maillist  -  [EMAIL PROTECTED]
= | http://lists.zope.org/mailman/listinfo/zope
= | **   No cross posts or HTML encoding!  **
= | (Related lists -
= |  http://lists.zope.org/mailman/listinfo/zope-announce
= |  http://lists.zope.org/mailman/listinfo/zope-dev )
=
= --
= Sidnei da Silva (dreamcatcher) [EMAIL PROTECTED]
= X3ng Web Technology http://www.x3ng.com.br
= GNU/Linux user 257852
= Debian GNU/Linux 3.0 (Sid) 2.4.19-pre6-ben0 ppc
=
= But what we need to know is, do people want nasally-insertable
= computers?
=



___
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] problems downloading CVS tarballs

2002-04-11 Thread Andrew Sydelko

When I try to download a CVS tarball of the Zope_2_5-branch branch, I get
a corrupt tar archive. The .../ISO_8859_1_Splitter/src directory 
contains one
c file whose name gets truncated. I'm using gnutar so I'm pretty sure 
it's not
a problem on my end.

What tar is used on the CVS server?

--andy.



___
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] can't put !--#BCODE -- in dtml

2002-04-11 Thread Eron Lloyd

Zope thinks you're trying to use an ancient version of DTML. Make sure
your comments are syntactically correct (!-- comment --) and try to
avoid using !-- #(comment) -- anywhere as this could trip you up down
the road. That format for variable insertion is still supported for
legacy reasons.

Regards,

Eron

On Thu, 2002-04-11 at 04:01, Yuan-Chen Cheng wrote:
 
 hi,
 
 Can't put !--#BCODE -- in dtml, but
 !-- #BCODE -- is okay.
 
 Is this correct.
 
 Thank you very much.
 
 Yuan-Chen Cheng
 
 The traceback is here:
 
 Unexpected tag, for tag !--#BCODE --, on line 8 of ttt
 
 Traceback (innermost last):
 File /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py, line
 150, in publish_module
 File /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py, line
 114, in publish
 File /home/ycheng/zope/zope/lib/python/Zope/__init__.py, line 158,
 in zpublisher_exception_hook (Object: ttt) File
 /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py,
 line 98, in publish File
 /home/ycheng/zope/zope/lib/python/ZPublisher/mapply.py,
 line 88, in mapply (Object: manage_edit) File
 /home/ycheng/zope/zope/lib/python/ZPublisher/Publish.py,
 line 39, in call_object (Object: manage_edit) File
 /home/ycheng/zope/zope/lib/python/OFS/DTMLDocument.py,
 line 79, in manage_edit (Object: ttt) File
 /home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
 320, in munge (Object: ttt) File
 /home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
 line 340, in cook (Object: ttt) File
 /home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
 line 162, in parse (Object: ttt)
 File /home/ycheng/zope/zope/lib/python/DocumentTemplate/DT_String.py,
 line 58, in parse_error (Object: ttt)
 Document Template Parse Error: (see above)
 
 
 
 
 ___
 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 )
 ---
 [This E-mail scanned for viruses by Declude Virus]
 
 


---
[This E-mail scanned for viruses by Declude Virus]



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