Phillip J. Eby wrote :
> Get rid of the "id_user" DTML method and add the following
> to a SkinScript method inside your UserSource:
>
> WITH QUERY SQL_id_user(username=self.id) COMPUTE id_user
>
> You should then be able to do "AUTHENTICATED_USER.id_user" to retrieve the
> attribute.
I had to up
At 12:19 PM 3/27/01 +0200, Bertrand Croq wrote:
>Hi,
> I am currently using LoginManager to authenticate users from a MySQL
>database. I followed the tutorials and it works quite well; but there are
>other data associated with users in the database that I would like to use in
>Zope. I have fou
Hi,
Bertrand CROQ schrieb:
>
> Hi,
> I am using Zope 2.3.0 with ZPatterns 0.4.3b2 and LoginManager 0.8.8b1. When
> I try to use LoginManager (following the tutorial about LoginManager and
> SQL), here is the error I get in the browser:
>
...
> The error seams to be in LoginMethods.py:149 a
"Morten W. Petersen" wrote:
>
> [Morten W. Petersen]
>
> | Any suggestions?
>
> Found the problem. There needs to be a method called user_names
> in the acl_users folder, which returns all the user ids:
[snip solution]
Sorry I didn't see your question earlier. Here was what I
posted to the li
Hi Morten,
> "Morten" == Morten W Petersen <[EMAIL PROTECTED]> writes:
Morten> (Can't understand why I had to use an additional list
Morten> though).
You probably found that Zope doesn't allow you to access the
elements of a BTree object (which is what you get from
"persistentIte
[Morten W. Petersen]
| Any suggestions?
Found the problem. There needs to be a method called user_names
in the acl_users folder, which returns all the user ids:
"""
self
user_ids = self.UserSource.getPersistentItemIDs()
user_ids2 = []
for id in user_ids:
user_ids2.append(id)
return
At 07:17 AM 11/28/00 +0100, Magnus Heino (Rivermen) wrote:
>
>
>I'd like to authenticate users using LDAP and Active Directory. Zope is
>running on a RH7.0 box.
>
>Has anyone done this, is it possible?
Dunno about Active Directory or RH 7, but Ty and I use LDAP logins with
LoginManager all the ti
[Phillip J. Eby]
| 0.8.6 won't work with 0.3.0 ZPatterns, IIRC. I'm pretty positive it
| requires one of the 0.4.x releases, but I'm not positive which one. You
| might be better off with the latest (current) releases of both.
Okay, I tried different ZPattern versions against the most recent
L
At 05:11 PM 10/15/00 +0200, Morten W. Petersen wrote:
>I've been fiddling a bit with the LoginManager; but can't seem to make
>it work.
>
>The product versions are ZPatterns 0.3.0 and LoginManager 0.8.6.
>
>(Downgraded the ZPatterns product because the LoginManager couldn't
>find a class named ..
Thanks!
I actually tried to make _owner a class attrib, but then I tried to add a LM
to a sub-folder ;-) It didn't work out... Would it be an ugly solution to
check whether the LM _is_ top-level, and if it is, make _owner a class attrib?
Would it work? Or is this solution only curing the symptoms
At 04:01 PM 10/6/00 +, Ty Sarna wrote:
>
>I think this is due to Shane's fix for allowing LM's as non-top-level
>acl_users. I had it originally so that _owner was a class attribute,
>which works fine. With the change, it was added as an instance
>attribute. Now, UnownableOwner is just an empty
In article <[EMAIL PROTECTED]>,
Jonas Juselius <[EMAIL PROTECTED]> wrote:
> The problem has to do with the ownership of the acl_users. When the
> LoginManager (acl_users) is created it sets the _owner attribute to
> UnownableOwner. This is fine, for if the acl_users folder is owned it results
...
Jonas Juselius wrote:
>
> Do you have any clue about the ownership bug in the LoginManager? I find it
> quite strange that an unowned object becomes owned whenever Zope is restarted
> (or when a method is added...). I suspect that the problem is within the
> ZPatterns modules, since it handles th
Cheers!
I actually tried to implement support for local roles in almost exactly the
same way as you did, but for some reason I didn't get it to work.
Perhaps I should look into the matter again... I just threw in the
user_names(), and getUserNames() into the LoginManager, added some dtml to
ha
Jonas Juselius wrote:
>
> Another thing which I have tried to do, is to add support for local roles to
> the LoginManager. At first it looked rather simple, but then I realized that
> it wasn't really _that_ simple, and dropped it because I don't have time... It
> would however be nice to have lo
[Phillip J Eby]
>> def retreiveItem(self, name):
>> self.f.write('Creating object for %s\n' % name)
>> return USER(name)
> Your retrieveItem isn't checking to see if the user exists. Also, you
> spelled it "retreive" when the correct spelling is "retrieve".
Yep, as soon as I noticed th
At 11:53 PM 8/20/00 +0200, Terje Malmedal wrote:
>
>I've written this, but it just does not work, all that happens is that
>it writes opened to /tmp/source.log
>
>class USER:
>"Just a little test"
>name= None
>roles = [ 'Anonymous' , 'member' ]
>domains = []
>
>def __init
Terje Malmedal wrote:
>
> [Bill Anderson]
> > Terje Malmedal wrote:
> >>
> >> Can anybody please provide a simple example of a working usersource
> >> written in python?
>
> > Look at the UserSource source for LoginManager and Membership.
>
> I did that. I feel I am missing something obvious.
>
[Bill Anderson]
> Terje Malmedal wrote:
>>
>> Can anybody please provide a simple example of a working usersource
>> written in python?
> Look at the UserSource source for LoginManager and Membership.
I did that. I feel I am missing something obvious.
What I do is:
* create a folder name
Terje Malmedal wrote:
>
> Can anybody please provide a simple example of a working usersource
> written in python?
Look at the UserSource source for LoginManager and Membership.
--
Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.
_
"Phillip J. Eby" wrote:
>
> At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote:
> >
> >The new security machinery actually provides a different way to solve
> >this problem. Since we now have an execution stack, we can limit that
> >stack, causing an exception to be thrown rather than letting it
>
At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote:
>
>The new security machinery actually provides a different way to solve
>this problem. Since we now have an execution stack, we can limit that
>stack, causing an exception to be thrown rather than letting it
>overflow the C stack. It would actual
"Phillip J. Eby" wrote:
> Shane's patch changes manage_addLoginManager to set ob._owner =
> UnownableOwner, which is good, because this ensures that
> AccessControl.Owned.Owned._deleteOwnershipAfterAdd() can del self._owner.
> (I think that Owned shouldn't be doing this this way, but as yet I don'
23 matches
Mail list logo
