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
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 state
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 want
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
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.
>
>
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 a
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
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
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 impress
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.
Okay, secon
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 up.
Trusted people!?
Ar
Jim Fulton wrote:
> 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.
Well, it's on the roadmap to move away from it. The use case of allowing
untrusted users to add Python code TTW to the
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.
Regards,
Stephan
--
Stephan Richter
Web Sof
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
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 un
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?
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 3, 2009, at 2:57 AM, Brian Sutherland wrote:
> Hi,
>
> We're using UUIDs a lot, and it's pretty painful that they are
> security
> proxied. They're in the standard library from python 2.5
> (http://docs.python.org/library/uuid.html) and are immutable according
> to the documentation.
"A
Hi,
We're using UUIDs a lot, and it's pretty painful that they are security
proxied. They're in the standard library from python 2.5
(http://docs.python.org/library/uuid.html) and are immutable according
to the documentation.
I think they meet all the all the requirements to be rocks. So unless
s
19 matches
Mail list logo
