Brian Lloyd wrote:
I forward-ported these to the 2.7 branch the head. Any testing
you can do to make sure I didn't break anything would be appreciated.
I'm having trouble understanding what you forward-ported and what you'd
like me to test. As far as I can determine
Brian Lloyd wrote:
I forward-ported these to the 2.7 branch the head. Any testing
you can do to make sure I didn't break anything would be appreciated.
Now I understand that you were responding to these messages:
I think the problem is same as reported by Kazuya Fukamachi
Hi
Brian Lloyd wrote:
I forward-ported these to the 2.7 branch the head. Any testing
you can do to make sure I didn't break anything would be appreciated.
Now I understand that you were responding to these messages:
I think the problem is same as reported by Kazuya Fukamachi
John Poltorak wrote:
I woulde be interested in converting an existing web site with numerous
fairly static pages into one managed by Zope.
How would I go about doing this?
It seems pretty tedious having to upload each file individually, which is
the only way I have found of doing it so far.
Douwe Osinga wrote:
Do other people recognize this pattern? Other solutions?
With DTML this is indeed the way to go. The other solution with be to
use ZPT.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**
Stuart Bishop wrote:
On 13/01/2004, at 4:19 PM, Stuart Bishop wrote:
The 'security audit work for the 2.7 branch' commit on 8th Jan made
the following change in PageTemplates/Expression.py:
As well as in other locations such as ZopeGuards.py.
I've opened http://collector.zope.org/Zope/1182
Hajime Nakagami wrote:
Hi
Sorry I have not execute Zope 2.7 or HEAD now.
But I think needs not only the patch,
http://cvs.zope.org/Zope/lib/python/OFS/dtml/properties.dtml.diff?r1=1.14r2=1.15
but also below
[patch to properties.dtml]
To repeat: patching properties.dtml will never be able
Hi guys -
I was trying to be responsive to getting the issue resolved, since
I'd like to make a (hopefully final) beta of 2.7 of Friday. I'll be
happy to check in (or have you check in) whatever fixes are needed
to give you the flexibility you need so long as it is b/w compatible,
but I won't
Tres Seaver wrote:
Stuart Bishop wrote:
On 13/01/2004, at 4:19 PM, Stuart Bishop wrote:
The 'security audit work for the 2.7 branch' commit on 8th Jan made
the following change in PageTemplates/Expression.py:
As well as in other locations such as ZopeGuards.py.
I've opened
Jim Fulton wrote:
Tres Seaver wrote:
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Here is Stuart's original post:
This has the side effect of not passing the name attribute to
my security assertion methods registered via
ClassSecurityInfo.setDefaultAccess:
Brian Lloyd wrote:
I was trying to be responsive to getting the issue resolved, since
I'd like to make a (hopefully final) beta of 2.7 of Friday. I'll be
happy to check in (or have you check in) whatever fixes are needed
to give you the flexibility you need so long as it is b/w compatible,
Brian Lloyd writes:
If you or Hajime can send me a patch against the current 2.7
branch, I'll make sure they get in before the beta is cut (or if
either of you are committers it is also fine to checkin yourselves
to the Zope-2_7-branch and head and let me know when its done).
Here is
Tres Seaver wrote:
Jim Fulton wrote:
Tres Seaver wrote:
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Here is Stuart's original post:
This has the side effect of not passing the name attribute to
my security assertion methods registered via
Hi Robert,
Hi Tres,
Adding 'guarded_hasattr' to the list of items wrapped items did not help.
I guess You have taken Tres too literally. I did the same (i.e. adding
the string 'guarded_hasattr' to the _NEED_WRAPPING list) and could
reproduce Your issue. After wandering through the code
Jim Fulton wrote at 2004-1-15 10:03 -0500:
...
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 10:03 -0500:
...
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 10:03 -0500:
...
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
In addition to this problem, someone has changed manage_form_title.dtml
and caused me grief!
The dtml-var title tag has been changed to dtml-title;
This causes an implicit html-quote to now be performed which means that
my img tag, inserted to display the product's icon to more strongly
Alan Milligan wrote:
In addition to this problem, someone has changed manage_form_title.dtml
and caused me grief!
The dtml-var title tag has been changed to dtml-title;
This causes an implicit html-quote to now be performed which means that
my img tag, inserted to display the product's icon to
Thanks,
Yuppie allredy pointed me to my error. Things work fine now.
Strange that this is not yet fixed in the CVS.
Robert
The only thing I am still figthing: LocalFS does not work under 2.7. You do
not happen to know how to fix it?
On Thursday 15 January 2004 19:45, Clemens Robbenhaar wrote:
Tres Seaver wrote:
Alan Milligan wrote:
In addition to this problem, someone has changed
manage_form_title.dtml and caused me grief!
The dtml-var title tag has been changed to dtml-title;
This causes an implicit html-quote to now be performed which means
that my img tag, inserted to display
On Fri, 16 Jan 2004, Alan Milligan wrote:
Tres Seaver wrote:
That change is one of a number which are designed to prevent
cross-site scripting attacks; DTML is particularly vulnerable to such
cracks, as it doesn't force the template writer to choose the source
from which the name
This indeed is a problem.
Isn't this an issue because all of these quasi-private methods have a
document string and are hence callable via an http request? If we were
to remove the doc string from manage_form_title (ie via rewriting this
as a python method which delegates to the underlying
-Original Message-
Sorry I have not execute Zope 2.7 or HEAD now.
But I think needs not only the patch,
http://cvs.zope.org/Zope/lib/python/OFS/dtml/properties.dtml.d
iff?r1=1.14r2=1.15
but also below
[patch to properties.dtml]
To repeat: patching properties.dtml will
Jim Fulton wrote at 2004-1-15 17:23 -0500:
BTW, telling me that an algorithm has changed doesn't constitute
a use case. :) I know that algorithm has changed. I assert that
we don't need the feature that the change broke. I am open
to evidence to the contrary.
Do you have a convincing reason to
Jim Fulton wrote at 2004-1-15 17:23 -0500:
...
None should never be passed for attribute accesses. If it is,
then there is a bug. The case of dictionary mapping names to
whatever is for attribute access. We are talking about item/key
access. I haven't seen a use case for needing to specify
26 matches
Mail list logo
