Martijn Faassen wrote:
Isn't zope.security a protection system against *accidental* mistakes in
building secure applications? I.e. I call a method and then I find out I
have no such access. Do we really need to protect the developer against
more arcane workarounds?
Yes, that's its stated
Martijn Faassen wrote:
b) prevent someone from viewing something with a public view because
they don't have access to content-level methods and attributes. (which I
take is your HTTP request as untrusted code scenario). (alternate
strategies are Grok's, which has view-level security but
Hi there,
One fundamental question about this that I have is why we want to
protect the user against such loopholes anyway?
Isn't zope.security a protection system against *accidental* mistakes in
building secure applications? I.e. I call a method and then I find out I
have no such access. Do
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote:
Hi there,
One fundamental question about this that I have is why we want to
protect the user against such loopholes anyway?
Isn't zope.security a protection system against *accidental*
mistakes in
building secure applications?
No
Jim Fulton wrote:
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote:
[snip]
Protecting against workarounds is useful if you allow through the web
manipulation of code itself. But who is actually doing this?
The purpose of the protection system is to protect an application
against
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote:
...
I know that Plone is moving away from untrusted code,
I predict they won't, but we'll see.
and Zope 2 isn't
using zope.security anyway.
That's immaterial. I was talking about the use case.
That leaves ZC's applications, which I
Hey,
Jim Fulton wrote:
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote:
and Zope 2 isn't
using zope.security anyway.
That's immaterial. I was talking about the use case.
It's hard to tell whether Zope 2 will ever adopt zope.security to
fulfill this use case - I have the impression
Zvezdan Petkovic wrote:
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote:
We do have the use-case of allowing trusted people to add templates or
code TTW and many other things like data level and view based
security.
The RestrictedPython case however is something we will gladly give
On Apr 10, 2009, at 12:26 PM, Martijn Faassen wrote:
...
b) prevent someone from viewing something with a public view because
they don't have access to content-level methods and attributes.
(which I
take is your HTTP request as untrusted code scenario).
It is an example of that scenario,
On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote:
We are in the business of content management. The most valuable
information the system and the entire physical machine has is the
content in the system. You don't run web applications on any kind of
shared servers where the system has any
Hey,
Jim Fulton wrote:
[snip]
I don't see the point of a separate package. This is a very small
corner of zope.security.
Sure, it could be solved within zope.security as well.
A simple API for extending the definition of rocks would be enough to
deal with this particular issue.
Note
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Keas is relying on that safety heavily too. Anyone who wants to build a
secure
DSL based on Python really wants zope.security.
On Apr 10, 2009, at 3:20 PM, Shane Hathaway wrote:
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Keas is relying on that safety heavily too. Anyone who wants to
build a
13 matches
Mail list logo
