In article [EMAIL PROTECTED] you write:
Note that you'll also want to change validate() if you go that route.
It has a short-circuited version of getRolesInContext in it.
are you sure it's not BasicUser.allowed() that you mean?
there's a comment in there about checking roles manaully
hm... i could have told you that the LDAPUser class in the
LDAPUserFolder product can do that but i had the whole thread mostly
tuned out. initially it did not look like anything i could help with
and the first posting was very long if i remember correctly.
jens
On Thursday, Mar 6, 2003, at
On March 5, Paul Winkler wrote:
* more coupling
Yes.
* performance hit
Yes.
* one more detail to pay attention to
Yes.
OTOH, doing the magic in user.allowed() would mean
I'd only need one special UserFolder instance at the top of the
hierarchy, and then everything else Just Works
On Fri, Mar 07, 2003 at 08:56:59AM +1100, Adrian van den Dries wrote:
(/me revisits LDAPUserFolder)
Looks like the work is already done for you anyway: allowed() and
friends check if the context has an attribute acl_satellite, and
queries it for any additional roles, and it even keeps a
On March 5, Paul Winkler wrote:
I've been trying to understand how to implement dynamic local roles,
Customise the Folder class and override __ac_local_roles__ with a
method that returns a dictionary mapping users to roles for that object:
{user: [local,roles],
...}
*
On Tue, Feb 25, 2003 at 06:33:16PM +, Florent Guillaume wrote:
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:
So I think you need dynamically calculated local roles. This can be
achieved by a user folder that returns a user object that overrides
.getRolesInContext(object) to take
Paul Winkler wrote:
On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:
Since your application might not be suited for that scheme, it might be
worth throwing out roles altogether. How about creating a role for each
user (i.e. user user_id get's just the role user_id, instead of
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:
So I think you need dynamically calculated local roles. This can be
achieved by a user folder that returns a user object that overrides
.getRolesInContext(object) to take the location (or any other
attribute, such as an acquired site) of
Paul Winkler wrote at 2003-2-24 16:27 -0500:
...
It is easy to optimize this to u + a (via a dictionary),
then thousands of roles should not be a problem.
would that mean you have to build a (potentially huge) dictionary every
time? I'd greatly appreciate it if you could
On Tue, Feb 25, 2003 at 11:33:54PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2003-2-24 16:27 -0500:
...
It is easy to optimize this to u + a (via a dictionary),
then thousands of roles should not be a problem.
would that mean you have to build a (potentially huge)
Paul Winkler wrote:
On Sat, Feb 22, 2003 at 02:24:10PM +0100, Oliver Bleutgen wrote:
With locations, do you mean physical locations of the clients (i.e.
IP-adresses), or the locations of objects inside zope (i.e.
/department1, /department2 etc.)?
Both.
Let's call them sites instead of
On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:
From that I gather that your sites don't map 1:1 to objects into
zope, so that you cannot use local roles for that, right?
E.g, there are methods like doTaskX(location,...), where the permission
to execute that method depend on
I don't think a multitude of roles is the way to go. The way your
problem sounds, you need users being allowed/forbiden to do certain
tasks depending on which part of the site they are. This is what
local-roles are for: parameterizing the permissions of a user based on
the location of the objects
On Sun, Feb 23, 2003 at 09:02:24PM +0100, Dieter Maurer wrote:
I think (not sure, though) that Zope has the following time
complexity for permission checking:
If a user has u roles and a permission is allowed for
a roles, then Zope checks for each of the u roles
whether it is in the
On Mon, Feb 24, 2003 at 07:18:21PM -0300, Leonardo Rochael Almeida wrote:
I don't think a multitude of roles is the way to go. The way your
problem sounds, you need users being allowed/forbiden to do certain
tasks depending on which part of the site they are. This is what
local-roles are
On Mon, 2003-02-24 at 19:07, Paul Winkler wrote:
On Mon, Feb 24, 2003 at 07:18:21PM -0300, Leonardo Rochael Almeida wrote:
I don't think a multitude of roles is the way to go. The way your
problem sounds, you need users being allowed/forbiden to do certain
tasks depending on which part
Paul Winkler wrote at 2003-2-21 16:28 -0500:
has anybody ever set up a site with a large number of roles?
we're contemplating a security model for our app that might
lead to ~ 100 Roles within a year, possibly thousands
within the next 5 years. (Outline of the actual problem is
at the
Paul Winkler wrote:
more about our scenario:
* We must anticipate users at hundreds of locations
* there might be 10 or so users at each location
* permissions can be grouped pretty well into tasks, but are
specific to a location - permission to do a task at one
location must not mean
On Sat, Feb 22, 2003 at 02:24:10PM +0100, Oliver Bleutgen wrote:
With locations, do you mean physical locations of the clients (i.e.
IP-adresses), or the locations of objects inside zope (i.e.
/department1, /department2 etc.)?
Both.
Let's call them sites instead of locations, because they're
has anybody ever set up a site with a large number of roles?
we're contemplating a security model for our app that might
lead to ~ 100 Roles within a year, possibly thousands
within the next 5 years. (Outline of the actual problem is
at the end of this message)
(The users and roles will be
20 matches
Mail list logo
