> > if I access /dir2/index_html comes the user object from LRT2 ?
> > what if I access in /dir2/index_html aq_parent.dir1.index_html.
> > Will the AUTHENTICATED_USER change ? will the user object come from LRT2
> > ?
>
> No, it will not. Only one user ever applies to a request.
And that exact
Dirk Datzert wrote:
def getRolesInContext(self, obj):
lrt = obj.acl_users # get nearest acl_users for obj (not really sure
if this works ?)
user = lrt.getUser ( self.getId(), self._getPassword() )
return user.getRoles()
Hmm, no, the user object is simply "self".
yes wrong question ;-)
>>
> >> Where is the LDAPUser class located?
> >
> >
> > imported from the LDAPUserFolder module
>
> Ok, that does make it a little more complicated.
>
Why ?
For me it is the same if I import LDAPUser from LDAPUserFolder and
overwrite some functions, or import LDAPUser from LDAPRoleTwiddler
(wh
> > def getRolesInContext(self, obj):
> >lrt = obj.acl_users # get nearest acl_users for obj (not really sure
> > if this works ?)
> >user = lrt.getUser ( self.getId(), self._getPassword() )
> >return user.getRoles()
>
> Hmm, no, the user object is simply "self".
>
yes wrong question
Jens Vagelpohl wrote:
Dirk Datzert wrote:
LDAPUser from LDAPUserFolder inherits getRolesInContext from BasicUser,
right ?
LDAPRoleTwiddler caches LDAPUser entries with changed 'local' roles.
Where is the LDAPUser class located?
imported from the LDAPUserFolder module
Ok, that does make i
Dirk Datzert wrote:
LDAPUser from LDAPUserFolder inherits getRolesInContext from
BasicUser,
right ?
LDAPRoleTwiddler caches LDAPUser entries with changed 'local' roles.
Where is the LDAPUser class located?
imported from the LDAPUserFolder module
jens
Jens Vagelpohl wrote:
i was always under the impression that getRolesInContext is not getting
called in all places where it should be called. that was one of the
reasons i went for a "replace all global user roles" approach.
i might be wrong... (which would be nice because using shane's idea
Dirk Datzert wrote:
LDAPUser from LDAPUserFolder inherits getRolesInContext from BasicUser,
right ?
LDAPRoleTwiddler caches LDAPUser entries with changed 'local' roles.
Where is the LDAPUser class located?
What user object will be used if you talk about 'user objects' ?
user objects out of L
i was always under the impression that getRolesInContext is not getting
called in all places where it should be called. that was one of the
reasons i went for a "replace all global user roles" approach.
i might be wrong... (which would be nice because using shane's idea
sounds like it could si
Shane Hathaway schrieb:
>
> Dirk Datzert wrote:
> >>And if you're interested, I know how we can make LDAPRoleExtender much
> >>safer, based on conversations with Jens.
> >>
> >
> > Sure I'm interessted.
>
> Ok. All User objects have a getRolesInContext() method. All this
> method does right n
Hi Shane,
thanks for answering.
> >>
> >> Maybe I'm think too complicated, Your opinion ?
>
> The idea behind LDAPRoleExtender is to give the user global roles if the
>
> I don't know anything about LDAPRoleTwiddler. But I would recommend you
> install the VerboseSecurity product, which will t
Dirk Datzert wrote:
And if you're interested, I know how we can make LDAPRoleExtender much
safer, based on conversations with Jens.
Sure I'm interessted.
Ok. All User objects have a getRolesInContext() method. All this
method does right now is scan the acquisition context for
__ac_local_r
Jens Vagelpohl wrote:
being explicit is almost always better. you are relying on internal
magic and it's not apparent from looking at the code you wrote.
the validate implementation in the LDAPRoleExtender is the "most
correct" one. shane worked on it for a while to make sure it does the
most
if shane's "validate" does not work then i assume there is a separate
issue independent from it.
jens
On Thursday, Oct 17, 2002, at 08:56 US/Eastern, Dirk Datzert wrote:
Hi Jens,
if I take the following code:
# This must stay accessible to everyone
def validate( self, request, auth=
being explicit is almost always better. you are relying on internal
magic and it's not apparent from looking at the code you wrote.
the validate implementation in the LDAPRoleExtender is the "most
correct" one. shane worked on it for a while to make sure it does the
most correct thing possible,
Hi Jens,
if I take the following code:
# This must stay accessible to everyone
def validate( self, request, auth='', roles=_noroles ):
""" The main engine """
luf = self.getLUF()
v = request['PUBLISHED'] # the published object
a, c, n, v = luf._getobcontex
Hi Jens,
> why is that code no longer referring to the real userfolder anymore? it
> should not make calls to authorize/identify/authorize on "self" but on
> the LDAPUserFolder it is using as the user source.
>
self.identify() should be the same as if getLUF().identify() since LDAPUserFolder a
why is that code no longer referring to the real userfolder anymore? it
should not make calls to authorize/identify/authorize on "self" but on
the LDAPUserFolder it is using as the user source.
jens
On Thursday, Oct 17, 2002, at 03:39 US/Eastern, Dirk Datzert wrote:
Hi all,
I try to solve so
Hi all,
I try to solve some problems with LDAPRoleTwiddler an inherited version from
BasicUserFolder
I currently use a validate()-function which I saw similar in BasicUserFolder and in
LDAPRoleExtender (modifications from Shane)
My problem is that
if self.authorize(user, a, c
19 matches
Mail list logo
