<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Tres Seaver wrote:
<blockquote cite="mid43F4045D.4080909@palladion.com" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Shulman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2/15/06, Chris Withers <a class="moz-txt-link-rfc2396E" href="mailto:chris@simplistix.co.uk"><chris@simplistix.co.uk></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">But... it's still not working for my real site. I think the issue is
this. If script1 has proxy role Manager, and script2 has view
permissions set only for Manager, then script1 can call script2, no
problem. But if script1 instead calls script3, which then calls
script2, it doesn't work unless script3 *also* has proxy role Manager.
</pre>
</blockquote>
<pre wrap="">Yes, this was a deliberate change made a few major releases ago. I've
never mich liked it myself for exactly the reason you describe. I wonder
if anyone who knows could point out why this change was made, I'm sure
the reasons were good...
</pre>
</blockquote>
<pre wrap="">
Even if the reasons were good, it would be nice to have an option to
turn it on or off, even if the default is off. At the very least, it
would be nice if this fact were documented. (Is it somewhere and I
just missed it?) It surprised me very much, and it would have
surprised and frustrated me even more if I'd written a site which
worked and then later on decided to split off the functionality of
some private script into a secondary one, unsuspecting that it would
break the proxy roles setup.
</pre>
</blockquote>
<pre wrap=""><!---->
The prior behavior (allowing users to access protected resources "above"
the domain of their user folders) was a security hole caused by a bug,
and was never documented as allowable: correcting it was a matter for a
rather urgent fix, as it broke the explicitly-documented model.
The fact that folks wrote applications which relied on the hole is
unfortunate; breaking them is better than leaving the sites built
around the defined model vulnerable to abuse.
Tres.
-</pre>
</blockquote>
Hi Tres,<br>
<br>
I just disagree. If theres a paranoia with the standard set of roles
then prevent *those* from upward acquisition. But if I add a role
*specifically* so it can access a common code pool, say like
"/commonPython" and "/commonJavascript" thats available to sub-folders,
probably distinquished by data adapter access to various companies ...
than whats the downside? The upside is that I dont have to copy one
code improvement across n number of sub-folder instances.<br>
<br>
<br>
David<br>
<br>
</body>
</html>