Re: [Zope-dev] LoginManager question

[Bertrand Croq]

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 update ZPatterns (md error) and configure STUPID_LOG_FILE (I/O 
error) but it works.

Thanks a lot.
-- 
Bertrand Croq - VIRTUAL NET (http://www.virtual-net.fr)
80, avenue des Buttes de Coesmes - 35700 RENNES
tel: +33 2 23 21 06 30 - fax: +33 2 99 38 16 85

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager question

[Phillip J. Eby]

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 found a solution but I think it is quite complicated:
>
>- first, I added SQL_id_user (ZSQL-method) in the acl_users:
>
>select id_user
>from user
>where 
>
>- then, I added id_user (DTML-method) in the acl_users:
>
>
>   
>
>
>- now, when I want to get the id_user value associated with the current
user, 
>I need to do:
>
>
>   expr = "AUTHENTICATED_USER.id_user(
>   AUTHENTICATED_USER,
>   username=AUTHENTICATED_USER
>  )"
> >
>
>
>Isn't there an easier way to get the id_user value?
>

Yes, there is.  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.  


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager question

[Bertrand Croq]

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 found a solution but I think it is quite complicated:

- first, I added SQL_id_user (ZSQL-method) in the acl_users:

select id_user
from user
where 

- then, I added id_user (DTML-method) in the acl_users:


   


- now, when I want to get the id_user value associated with the current user, 
I need to do:


 


Isn't there an easier way to get the id_user value?

-- 
Bertrand Croq - VIRTUAL NET (http://www.virtual-net.fr)
80, avenue des Buttes de Coesmes - 35700 RENNES
tel: +33 2 23 21 06 30 - fax: +33 2 99 38 16 85

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager

[Srinath Mantripragada]

Hi,

I want to know howto use multiple usersSource in Login Manager, if it's
possible.

I have added 2 usersSoucers and created diferent methods for each
usersSource, but it authenticates only within the first userSource Listed.






--
Srinath Mantripragada
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager error

[Jochen Knuth]

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 as it calls user.authenticate()
> with two parameters where LoginUser's authenticate() takes 3
> parameters; but, once again, I might be missing something as I am a
> beginner...
> 

As far as i know LoginManager 0.8.8b1 is not compatible with Zope 2.3.0.
There are also some Problems with ZPatterns and Zope 2.3.0 (see the
recent thread "ZPatterns for Zope 2.3 convenience release")

Ciao,
Jochen 
-- 
--
Jochen Knuth  WebMaster http://www.ipro.de
IPRO GmbH Phone ++49-7152-93330
Steinbeisstr. 6   Fax ++49-7152-933340
71229 LeonbergEMail: [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager error

[Bertrand CROQ]

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:

Type: TypeError
Value: not enough arguments; expected 3, got 2

Traceback (innermost last):
  File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 222, 
in publish_module
  File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 187, 
in publish
  File /usr/local/Zope-2.3.0-src/lib/python/Zope/__init__.py, line 221, in 
zpublisher_exception_hook
(Object: Traversable)
  File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 162, 
in publish
  File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/BaseRequest.py, line 
444, in traverse
  File /usr/local/zope/lib/python/Products/LoginManager/LoginManager.py, line 
237, in validate
(Object: ProviderContainer)
  File /usr/local/zope/lib/python/Products/LoginManager/LoginMethods.py, line 
149, in findLogin
(Object: PlugInBase)
  File /usr/local/Zope-2.3.0-src/lib/python/Shared/DC/Scripts/Bindings.py, 
line 324, in __call__
(Object: authenticate)
  File /usr/local/Zope-2.3.0-src/lib/python/Shared/DC/Scripts/Bindings.py, 
line 353, in _bindAndExec
(Object: authenticate)
  File 
/usr/local/Zope-2.3.0-src/lib/python/Products/PythonScripts/PythonScript.py, 
line 330, in _exec
(Object: authenticate)
(Info: ... cut ...)
TypeError: (see above)

I don't know a lot about Zope/Python (I work on it since 2 weeks) so I don't 
know if this is an install error, a development error (I mean, did I do 
something wrong when using LoginManager, surely!!), or an error in 
LoginManager; is this a known error?

The error seams to be in LoginMethods.py:149 as it calls user.authenticate() 
with two parameters where LoginUser's authenticate() takes 3 
parameters; but, once again, I might be missing something as I am a 
beginner...

Thanks
-- 
Bertrand Croq - VIRTUAL NET (http://www.virtual-net.fr)
80, avenue des Buttes de Coesmes - 35700 RENNES
tel: +33 2 23 21 06 30 - fax: +33 2 99 38 16 85

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager and Control_Panel - The Never Ending Story

[Itai Tavor]

Hi,

I posted several questions about this problem, but got no replies. I 
thought I'd try again with a bit more information.

The problem is accessing Control_Panel from a folder that contains a 
LoginManager. I tested the same setup using a plain acl_users and 
found one difference.

Zope/
acl_users/
   user_1 (Manager)
Test1/
   acl_users/ (User Folder)
  user_2 (Manager)
   cnt1 (owned by user_1, Manager proxy role)
   cnt2 (owned by user_2, Manager proxy role)
Test2/
   acl_users/ (LoginManager)
  user_3 (Manager)
   cnt1 (owned by user_1, Manager proxy role)
   cnt2 (owned by user_3, Manager proxy role)

cnt1 and cnt2 are DTML Methods containg: 

Logging in to /Test1/ with user_2, both /Test1/cnt1 and /Test1/cnt2 
return the Control_Panel object.

Loggin in to /Test2/ with user_3, /Test2/cnt1 return the 
Control_Panel object. /Test2/cnt2 returns KeyError: Control_Panel. 
ZDebug reports:

 Unauthorized: User itai, who is the owner of
 /OzCoasters/cnt2, is defined in the context of
 /OzCoasters, which is not an ancestor of
 /Control_Panel.

Hope anyone can understand this... it's confusing the stuffing out of 
me. But basically, the Manager proxy role allows a method to access 
Control_Panel regardless of where its owner and the logged in user 
are defined. But with LoginManager, Control_Panel is only accessible 
if the owner is defined in a regular User Folder above the 
LoginManager.

Any idea why this is happening? Any suggestions on how to test it? I 
know it's more likely to be a problem in my implementation of the 
user-supplied parts of LoginManager than a bug in LM... but my LM 
works in all other ways, and it doesn't seem to be doing anything 
wrong.

Any help would be, er, helpful (To borrow the words of King Arthur. 
Hey, a python reference! Do I get points for that?)
-- 
--
Itai Tavor  -- "Je sautille, donc je suis."--
[EMAIL PROTECTED]--   - Kermit the Frog --
-- 'Supposing a tree fell down, Pooh, when we were underneath it?' --
-- 'Supposing it didn't,' said Pooh after careful thought. --


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager and ZPatterns

[Morten W. Petersen]

Hi fellow zopers,

I don't know if it's a bug or feature, but whenever I try
to access parental objects from a user object in python
code, I can't seem to find anything.

That is, whenever I call acl_users.getItem('user123').getParentNode()
(the acl_users is a LoginManager instance) it returns None.  But,
if it's called from DTML, with exactly the same expression, it returns
the containing object...

Could someone shed some light on this?

Thank you.

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager and PTK

[Morten W. Petersen]

Hi guys,

I previously posted a couple of functions that enables users to
login at a lower level in the tree-structre than where the actual
user folder is.

I.e.,

a user could enter username and password at

/a

and get redirected to

/a/a/a/a/b

(the acl_users folder would be located in /a/a/a/a).

Now, there is a minor problem, because I can't seem to figure out
how to login the user to the actual context /a/a/a/a, except
maybe first redirecting the user to /a/a/a/a and then letting
the user log in from there..

Any thoughts / ideas?  And if you've got a completely different solution,
I'd be glad to hear it.  =)

Thanks.

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Loginmanager and local roles

[Michael Bernstein]

"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 list back in September when I was having the
same problem. Of course, it took me a whole week to figure
out.

http://lists.zope.org/pipermail/zope-dev/2000-September/006953.html

http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html

The second posting includes instructions for fixing
PersistentUserSouce.py, which is part of Membership.

Cheers,

Michael.

P.S. If you can help generalize the solution so it works for
multiple user sources, I'd be grateful.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Loginmanager and local roles

[Steve Spicklemire]

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 
"persistentItemIDs()" from dtml. You need to copy them
to a 'plain' list first (a 'plain' list is in the set of
object types that Zope allows you to use in DTML without
further security checking.. ). 

-steve




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Loginmanager and local roles

[Morten W. Petersen]

[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 user_ids2
"""

(Can't understand why I had to use an additional list though).

Cheers.

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] Loginmanager and local roles

[Morten W. Petersen]

Using LoginManager, I can't seem to map local roles to
users that are stored in LoginManager instances.

I.e.:

if this acl_users is a LoginManager

/a/b/c/acl_users

then any object in

/a/b/c/d

will not show any of the users stored in the nearest
acl_users object in the local roles management menu..

Any suggestions?

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Loginmanager and LDAP

[Phillip J. Eby]

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 time on several applications.  We've made a custom
UserSource for ease of installation on different apps, but we originally
developed it using a GenericUserSource and the ZopeLDAP product.  You
should be able to do the same.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] Loginmanager and LDAP

[Magnus Heino (Rivermen)]

Hi.

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?

/Magnus

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager & Acquisition Problem

[Charlie Wilkinson]

Greetings Fellow ZoPeople,
I'm having some difficulty with Acquisition of security settings within
LoginManager protected folders.  I'm using the latest CVS of Zope and
LM 0.8.8b1 with the included ZPatterns and Plugins.  It was necessary
to apply a patch (from Luca Mearelli on this list) on HTTPRequest.py to
actually create the LM folder without raising a NameError exception on
'path.'  I previously worked all the wrinkles out of my UserSource,
etc., under Zope 2.1.2., so my difficulties in this case are purely
upgrade related.

Folders/Objects thusly:

/ (Root Folder)
test (Test Folder)
acl_users (LoginManager)
index_html (Test Page)

If I change the security settings on index_html to allow access from a
test account role, all works fine.  If however, I change the security
settings on the test folder instead of index_html, it does not have the
expected effect and I get the forbiddenpage, as if acquisition of these
settings were not working.  I did not turn off "Acquire Settings" on
index_html.  Pretty much all such settings have been left at the default
settings except for adding the new roles to the test folder and enabling
them in either the test folder or on the index_html object as indicated.

As with may other things Zope & Python, I don't understand yet how LM
interacts with the mechanics of acquistion and security settings.  Has
anyone else tackled this yet who could provide some insights and/or a fix?

Thanks in advance,
Charlie

-- 
~
Charlie Wilkinson - [EMAIL PROTECTED] - N3HAZ
Parental Unit, UNIX Admin, Homebrewer, Cat Lover, Spam Fighter, HAM, SWLer...
Visit the Radio For Peace International Website: http://www.rfpi.org/
~
CLOBBER INTERNET SPAM:  See!! 
   Join!! 
~
QOTD:
"Bush is a big corporation disguised as a human being running for president."
-- Ralph Nader on David Letterman (9/28/00)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager and ZPatterns

[Morten W. Petersen]

[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
LoginManager (0.8.7a1) and 0.4.2a2 worked!

| If that still doesn't work for you, Ty is very close to releasing an 0.8.8
| LM, and I'm about as close to releasing 0.4.3 ZPatterns.  Both will be
| beta-quality releases, which is to say better than anything we've put out
| on either product so far.  :)  0.4.3 ZPatterns will even have some
| documentation in it.  :)  I expect that we will make our releases some time
| during this coming week.

I'm looking forward to it.  Especially some documentation.  =)

Thanks.

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager and ZPatterns

[Phillip J. Eby]

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 .. SheetProviderContainer, I think).

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.

If that still doesn't work for you, Ty is very close to releasing an 0.8.8
LM, and I'm about as close to releasing 0.4.3 ZPatterns.  Both will be
beta-quality releases, which is to say better than anything we've put out
on either product so far.  :)  0.4.3 ZPatterns will even have some
documentation in it.  :)  I expect that we will make our releases some time
during this coming week.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager and ZPatterns

[Morten W. Petersen]

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 .. SheetProviderContainer, I think).

When adding a LoginManager object, it raises a TypeError exception, on
line 313 in PlugIns.py, saying that a keyword parameter was redefined.

I've also been looking around for some useful documentation and searched
the mailing-lists..

Anyone had success with these two products, and would care to share a
howto?

Thanks in advance.

-Morten

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Jonas Juselius]

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, while the
patient is dying of cancer?

I also realized that LM:s support local roles, and I had it pointed out to me
that the reason for the default behaviour, is the scaling of Zope... I now have
a different scheme in mind...

Take care,
 .jonas.

On Fri, Oct 06, 2000 at 04:01:01PM +, Ty Sarna wrote:
> 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
> ...
> > The problem is that the acl_users folder becomes _owned_ (by whom I don't
> > know) every time Zope is restarted, or when any method is edited or added in
> 
> 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 list, []. Zope checks
> for UnownableOwner using an identity check, that is in python: "_owner is
> UnownableOwner". When the LM is pickled to ZODB and reloaded, _owner is
> still an empty list, but it's not *the* empty list. That is, in python
> terms: it's still *equal* to UO, but it isn't "is" UO.
> 
> We could go back to just having it as a class attribute, but then that
> breaks when adding a LM anywhere other than the top folder, because Zope
> wants to delete the _owner from it.
> 
> > 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 local roles support in the LoginManager, as it
> > would make it more complete.
> 
> LM supports local roles fine. Unfortunately, the Zope's treatment of
> them doesn't scale (a listview just doesn't work for 1500 users, and
> other parts of the machinery want to do things like "Get me a list of
> all local roles for all users" just so that it can see if *one* user has a
> specific role or set of roles.) We've submitted patches for some things,
> but not gotten much interest from DC.
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )

-- 
And what is good, Phaedrus,
And what is not---
Need we ask anyone to tell us these things?

[ PGP public key: http://www.iki.fi/jonas/pubkey.asc ]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Phillip J. Eby]

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 list, []. Zope checks
>for UnownableOwner using an identity check, that is in python: "_owner is
>UnownableOwner". When the LM is pickled to ZODB and reloaded, _owner is
>still an empty list, but it's not *the* empty list. That is, in python
>terms: it's still *equal* to UO, but it isn't "is" UO.
>
>We could go back to just having it as a class attribute, but then that
>breaks when adding a LM anywhere other than the top folder, because Zope
>wants to delete the _owner from it.

Actually, Ty, AFAIK this is now fixed in Zope 2.2.x;  IIRC Brian made some
changes to the ownership machinery to deal with _owner being a class
variable.  We should probably put out a new LM release to go with ZPatterns
0.4.3.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Ty Sarna]

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
...
> The problem is that the acl_users folder becomes _owned_ (by whom I don't
> know) every time Zope is restarted, or when any method is edited or added in

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 list, []. Zope checks
for UnownableOwner using an identity check, that is in python: "_owner is
UnownableOwner". When the LM is pickled to ZODB and reloaded, _owner is
still an empty list, but it's not *the* empty list. That is, in python
terms: it's still *equal* to UO, but it isn't "is" UO.

We could go back to just having it as a class attribute, but then that
breaks when adding a LM anywhere other than the top folder, because Zope
wants to delete the _owner from it.

> 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 local roles support in the LoginManager, as it
> would make it more complete.

LM supports local roles fine. Unfortunately, the Zope's treatment of
them doesn't scale (a listview just doesn't work for 1500 users, and
other parts of the machinery want to do things like "Get me a list of
all local roles for all users" just so that it can see if *one* user has a
specific role or set of roles.) We've submitted patches for some things,
but not gotten much interest from DC.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Michael Bernstein]

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 the persistance of the LoginManager...
> This is how the LoginManager is inited and ownership is set:

No, sorry.

What I did while hacking on LM was create it in a subfolder,
mess with it until it worked right, then (as superuser) copy
it, switch to the root folder, delete the acl_users folder
there, and paste the LM (also named acl_users, of course).

After that, it just worked, so I never encountered your
particular problem.

Michael Bernstein.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Jonas Juselius]

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
handle SQL and... it didn't work, so I dropped it... ;-) I'll try to come up
with some nice way to handle local roles in a proper way in the LoginManager,
and hope that I get my patches accepted :-)

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 the persistance of the LoginManager...
This is how the LoginManager is inited and ownership is set:

ob=LoginManager()
ob._owner=UnownableOwner
self._setObject('acl_users', ob)

I tried to make _owner a global attribute of the LoginManager, but that didn't
solve the problem. I have also written Ty Sarna, but I have not received any
response yet.

One more thing... I'm new to PythonMethods, and I would like to know how to
get access to the self attirbute (or the DTML namespace if you like) from
PythonMethods. I would like to use PythonMethods more, beacuse dtml quickly
becomes unreadable and ugly, and Python is always beautiful :-) 

Have a nice day,
 .jonas.

On Thu, Oct 05, 2000 at 08:11:45AM -0700, Michael Bernstein wrote:
> 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 local roles support in the LoginManager, as it
> > would make it more complete.
> > 
> > I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and
> > LoginManager-0_8_7a1.
> 
> I used Membership 0.7.6 on top of what you've got, and added
> support for local roles as detailed in this posting:
> 
> http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html
> 
> This ought to give you the clues you need to add the
> neccessary getUserNames method to a SQL User Source, and
> make the LoginManager user_names modification as well. If
> you have any ideas on how to generalize the user_names
> method, I'd like to hear them.
> 
> Let me know how it goes,
> 
> Michael Bernstein.

-- 
And what is good, Phaedrus,
And what is not---
Need we ask anyone to tell us these things?

[ PGP public key: http://www.iki.fi/jonas/pubkey.asc ]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager ownership bug!

[Michael Bernstein]

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 local roles support in the LoginManager, as it
> would make it more complete.
> 
> I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and
> LoginManager-0_8_7a1.

I used Membership 0.7.6 on top of what you've got, and added
support for local roles as detailed in this posting:

http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html

This ought to give you the clues you need to add the
neccessary getUserNames method to a SQL User Source, and
make the LoginManager user_names modification as well. If
you have any ideas on how to generalize the user_names
method, I'd like to hear them.

Let me know how it goes,

Michael Bernstein.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager ownership bug!

[Jonas Juselius]

Hola,

There seems to be a problem with the ownership model in Zope (or ZPatterns). 

The problem is the following: I have implemented a nice login system based on
the LoginManager and SQL methods. I would like to make this acl_users the
top level user folder, but... then hell brakes lose... 

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
in various errors: Excessive recursion or ValueError: unpack list of wrong
size (when logging in), IndexError: list index out of range (when trying to
view ownership info of acl_users). This has to do with the top-level folder
being unowned, it seems. There is no problem with the LoginManager being owned
in a folder which is owned itself.

The problem is that the acl_users folder becomes _owned_ (by whom I don't
know) every time Zope is restarted, or when any method is edited or added in
the acl_users folder. It seems that the _owned attribute is not persistent, or
that something, somewhere changes it. I have a dirty fix for the moment,
consisting of an external method which sets the ownership of acl_users to
UnownableOwner. This is however a far from satisfying solution...

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 local roles support in the LoginManager, as it
would make it more complete.

I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and 
LoginManager-0_8_7a1.

Best regards, 
  .jonas.


--
***
 Jonas Juselius   e-mail...: [EMAIL PROTECTED]
  voice: +358 9 191 40188 
 P.O. Box 55/ Department of Chemistry GSM..: 040 506 6599 
 FIN-00014 University of Helsinki fax..: +358 9 191 40169 
 FINLAND  http://www.iki.fi/jonas   

 Home address:
  Helsinginkatu 16 B 42   tel..: +358 9 753 3369
  00500 Helsinki
  FINLAND
***
[ GPG public key: http://www.iki.fi/jonas/pubkey.asc ]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager NT plugins?

[Robin Becker]

anyone doing user authentification with NT + Loginmanager?
-- 
Robin Becker

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager.

[Terje Malmedal]

[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 the misspelling I was able to figure out
what went on. So I've got a working usersource now. Thankyou.


-- 
 - Terje
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager.

[Phillip J. Eby]

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__(self, name):
>self.name = name

The above will not work, because UserSources *must* provide a user object
which subclasses from LoginUser.


>class SolidUserSource(BasicUserSource):
>
>""" Solid User Source """
>
>__plugin_kind__ = "User Source"
>meta_type   = "Solid User Source"
>f = open("/tmp/source.log",'a',0)
>f.write("opened\n")
>
>#def __init__(id,title):
>#self.f.write("init %s %s\n" % (id,title))
>#self.id = id
>#self.title = title
>
>def existsUser(self, name):
>self.f.write('Users exists %s\n' % name)
>return 1
>
>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".


>def rolesForUser(self, user):
>self.f.write('Returning roles for %s\n' % user.name)
>return user.roles
>
>def domainsForUser(self, user):
>self.f.write('Returning domains for %s\n' % user.name)
>return user.domains
>
>def authenticateUser(self, user, password, request):
>self.f.write('Authenticates user %s\n' % user.name)
>if user.name == 'aaa' and password == 'aaa':
>return 1 == 1
>return 1 == 0

These methods never get called because the code that calls them is in the
LoginUser class, which you have not subclassed your user from.

You may want to consider simply configuring a GenericUserSource; you can
always use ExternalMethods to do so.  It is not so much that making a
custom user source is hard, as that it effectively requires an
understanding of how to subclass the ZPatterns "Rack" concept, and you may
not wish to expend that much effort simply to create a custom user source.
Once you've created a GUS that works as you wish, you can always subclass
GUS and hardwire your working methods into it, if your needs call for a
pure-python, quickly installable solution.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager.

[Bill Anderson]

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.
> 
> What I do is:
> 
>   * create a folder named "/test"
>   * inside /test I choose login manager from the "avaliable objects" drop down.
>   * select "solid user source" from the menu.
>   * press "add"
>   * create an index_html which Anonymous is not allowed to see.
> 
> When I access /test from an unauthenticated webbrowser it finds that
> it can't view it and pops up the username/password window, but neither
> retreiveItem nor anything else gets called.

Is your login form even calling the authenticate method? check your login method.


--
Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager.

[Terje Malmedal]

[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 named "/test"
  * inside /test I choose login manager from the "avaliable objects" drop down. 
  * select "solid user source" from the menu.
  * press "add"
  * create an index_html which Anonymous is not allowed to see. 

When I access /test from an unauthenticated webbrowser it finds that
it can't view it and pops up the username/password window, but neither
retreiveItem nor anything else gets called. 

Does anybody have any clues? 

I am using Zope 2.1.6 LoginManager 0.8.6 and ZPatterns 0.3.0 


-- 
 - Terje
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager.

[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.

--
Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager.

[Terje Malmedal]

Can anybody please provide a simple example of a working usersource
written in python?

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__(self, name):
self.name = name

class SolidUserSource(BasicUserSource):

""" Solid User Source """

__plugin_kind__ = "User Source"
meta_type   = "Solid User Source"
f = open("/tmp/source.log",'a',0)
f.write("opened\n")

#def __init__(id,title):
#self.f.write("init %s %s\n" % (id,title))
#self.id = id
#self.title = title

def existsUser(self, name):
self.f.write('Users exists %s\n' % name)
return 1

def retreiveItem(self, name):

self.f.write('Creating object for %s\n' % name)
return USER(name)

def rolesForUser(self, user):
self.f.write('Returning roles for %s\n' % user.name)
return user.roles

def domainsForUser(self, user):
self.f.write('Returning domains for %s\n' % user.name)
return user.domains

def authenticateUser(self, user, password, request):
self.f.write('Authenticates user %s\n' % user.name)
if user.name == 'aaa' and password == 'aaa':
return 1 == 1
return 1 == 0


-- 
 - Terje
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager patch considered harmful

[Shane Hathaway]

"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
> >overflow the C stack.  It would actually be more reliable than the
> >current mechanism, which depends on DTML namespaces.
> 
> That would probably be a good idea, independent of LoginManager et al.

Well, guess what... Jim's ahead of both of us.  Not only is the stack
size limited, but the limit is easily configured through an environment
variable.  I never give this guy enough credit. :-)  See
lib/python/AccessControl/SecurityManager.py, especially addContext().

> >If the LoginManager is created by the superuser and is used as the root
> >authenticator, it stays unowned, so the ownership problem should not
> >occur.  If that is not the current behavior then it needs to be
> >corrected.
> 
> That is not the current behavior, unless _owned=UnownableOwner is placed in
> the class.

It looks like Brian decided, for the latest beta, to make ownership
forgiving in the presence of an _owner class attribute.  This should
solve the problem for Generic User Source.  Generic User Folder is
going to need the _owner attribute.

> >If untrusted users are allowed to add LoginManagers, the methods called
> >to get ownership information should be owned by them.  This is to avoid
> >the server-side trojan horse.
> 
> Understood.  I'll try to keep that use case in mind.  Keep in mind,
> however, that being able to create a LoginManager is a pretty risky
> business in a portalish environment - you could potentially get access to
> somebody's password, since after all you will control an actual login
> screen!  (Note however, that someone can create a phony login screen in
> DTML and bypass the entire Zope security model with a little "social
> engineering" anyway.)

I've thought of that as well.  Perhaps we'll have to accept that the
new model just doesn't lend itself to the area of configurable user
databases.

> Also note that it is not necessary to give a user access to the full power
> of LoginManager.  One could give them rights only to add a small subset of
> the available UserSources and LoginMethods.  It would probably be a bad
> idea to give them the ability to add a GenericUserSource, which is where
> most of the potential for mayhem lies.  Better to give them some sort of
> PersistentUserSource, with no ability to do much.
> 
> >Now, the problem still remains that ownership information cannot be
> >retrieved if the method that gets ownership is in ZODB, is owned by a
> >user defined in that user folder, and has to call another method.  Note
> >that this also applies to Generic User Folder.
> 
> Yep.  The problem is that the superuser *can't* create those methods in the
> root folder, so there's no place to bottom out the recursion at present.
>
> >With the correction in the execution stack, instead of killing Zope, an
> >attempt to authenticate that way will result in a controlled stack
> >overflow.  Unless you can come up with another option, we can either
> >break the security model or slightly reduce the capabilities of
> >LoginManager.
> >
> >What would you do if you were in my position?
> 
> Well, I'm hoping you'll take a look at my Collector suggestion for a new
> Zope feature.  :)  Specifically, extending the "access" file to allow other
> "top-level" users to exist besides the superuser, who have roles defined in
> the file.  There are many ways this would be useful, not the least of which
> is to break the "you need to do that at the next level up" problem.
> (Others include a simplified process for getting your Zope site set up,
> since you then don't have to login as superuser and add a user folder, then
> log back in as somebody else.)
>
> If this were done, we could easily go to letting LoginManager objects be
> owned, since there'd always be a place "above" the LoginManager for the
> owner user to reside.

Hmm... this sounds like a good idea, but now that the ownership problem
has been resolved in a way I didn't expect, the issue that motivated
your idea is gone.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager patch considered harmful

[Phillip J. Eby]

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 actually be more reliable than the
>current mechanism, which depends on DTML namespaces.

That would probably be a good idea, independent of LoginManager et al.


>If the LoginManager is created by the superuser and is used as the root
>authenticator, it stays unowned, so the ownership problem should not
>occur.  If that is not the current behavior then it needs to be
>corrected.

That is not the current behavior, unless _owned=UnownableOwner is placed in
the class.


>If untrusted users are allowed to add LoginManagers, the methods called
>to get ownership information should be owned by them.  This is to avoid
>the server-side trojan horse.

Understood.  I'll try to keep that use case in mind.  Keep in mind,
however, that being able to create a LoginManager is a pretty risky
business in a portalish environment - you could potentially get access to
somebody's password, since after all you will control an actual login
screen!  (Note however, that someone can create a phony login screen in
DTML and bypass the entire Zope security model with a little "social
engineering" anyway.)

Also note that it is not necessary to give a user access to the full power
of LoginManager.  One could give them rights only to add a small subset of
the available UserSources and LoginMethods.  It would probably be a bad
idea to give them the ability to add a GenericUserSource, which is where
most of the potential for mayhem lies.  Better to give them some sort of
PersistentUserSource, with no ability to do much.


>Now, the problem still remains that ownership information cannot be
>retrieved if the method that gets ownership is in ZODB, is owned by a
>user defined in that user folder, and has to call another method.  Note
>that this also applies to Generic User Folder.

Yep.  The problem is that the superuser *can't* create those methods in the
root folder, so there's no place to bottom out the recursion at present.


>With the correction in the execution stack, instead of killing Zope, an
>attempt to authenticate that way will result in a controlled stack
>overflow.  Unless you can come up with another option, we can either
>break the security model or slightly reduce the capabilities of
>LoginManager.
>
>What would you do if you were in my position?

Well, I'm hoping you'll take a look at my Collector suggestion for a new
Zope feature.  :)  Specifically, extending the "access" file to allow other
"top-level" users to exist besides the superuser, who have roles defined in
the file.  There are many ways this would be useful, not the least of which
is to break the "you need to do that at the next level up" problem.
(Others include a simplified process for getting your Zope site set up,
since you then don't have to login as superuser and add a user folder, then
log back in as somebody else.)

If this were done, we could easily go to letting LoginManager objects be
owned, since there'd always be a place "above" the LoginManager for the
owner user to reside.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] LoginManager patch considered harmful

[Shane Hathaway]

"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't
> have a good alternative to propose that DC implement.)  The problem is that
> once this is done, the LoginManager is no longer "unowned".  To fix this,
> add the line:
> 
> _owner = UnownableOwner
> 
> to the body of the LoginManager class.  This will ensure that even after
> _deleteOwnershipAfterAdd(), the LoginManager will remain "unowned".

Your logic is sound, and I'm glad you spotted the recursion problem,
but I would like to propose a different solution.

> After you have made this fix and restarted Zope, you may want to "un-own"
> any objects contained within your LoginManagers which might have been
> created with ownership.  To do this, you should go to each page of each
> LoginManager's management interface and copy all objects, then paste them.
> Delete the originals, and rename the copies back to their old names.  The
> copies will then be "unowned".  You can verify this by checking each
> object's management interface: if it is unowned, it will have no
> "Ownership" tab.
> 
> Why does LoginManager want its contents unowned?  It has to do with the new
> security model.  When an executable object is owned, the security machinery
> wants to validate that its owner is allowed to do whatever the executable
> is doing.  This is great except for the fact that in many sites, the owner
> of the LoginManager's objects is actually a user that was retrieved from
> that LoginManager.  This means that if LoginManager executes an object to
> find out information about a user, and that object is owned by a user from
> that LoginManager, infinite recursion and a core dump will swiftly follow.
> For this reason, you should make sure that all executable objects in a
> LoginManager are either unowned or owned by a user who is *not* supplied by
> that LoginManager.  In practice, making sure they're unowned is usually
> easier.

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 actually be more reliable than the
current mechanism, which depends on DTML namespaces.

Now let's do an analysis of this situation.

If the LoginManager is created by the superuser and is used as the root
authenticator, it stays unowned, so the ownership problem should not
occur.  If that is not the current behavior then it needs to be
corrected.

If untrusted users are allowed to add LoginManagers, the methods called
to get ownership information should be owned by them.  This is to avoid
the server-side trojan horse.

I used to think that the new security model was a break from the *nix
security model.  But consider this: sysadmins don't go around executing
arbitrary users' scripts, do they?  Of course not.  The only parallel
to what Zope provides is CGI scripts.  Sysadmins are able to visit
arbitrary CGI scripts without worry of a server-destined trojan
(although a client-destined trojan is another matter) because the
scripts are not given extra privileges.  In fact, the suexec add-on
makes Apache behave almost exactly the way Jim is getting Zope to
behave.

Now, the problem still remains that ownership information cannot be
retrieved if the method that gets ownership is in ZODB, is owned by a
user defined in that user folder, and has to call another method.  Note
that this also applies to Generic User Folder.

With the correction in the execution stack, instead of killing Zope, an
attempt to authenticate that way will result in a controlled stack
overflow.  Unless you can come up with another option, we can either
break the security model or slightly reduce the capabilities of
LoginManager.

What would you do if you were in my position?

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager patch considered harmful (was Re: can't addloginmanager below root) loginmanager below root)

[Phillip J. Eby]

At 09:21 PM 6/28/00 +, Ty Sarna wrote:
>In article <[EMAIL PROTECTED]>,
>Shane Hathaway  <[EMAIL PROTECTED]> wrote:
>> Ok folks,
>> 
>> I thought I had made it clear that this problem has been solved.  I have
>> sent a patch to Ty (about two weeks ago) as well as made the change in
>
>Sorry for the delay. I'm just now cacthing up on all my zope-related
>mail. I've applied this patch, and it will be in the release tonight.
>However, I am a bit concerned about what happens if _owner is deleted.
>For purposes of setuid code, we'd like to use the owner as the user to
>setuid to, but if we can't force it to be the right user, that could be
>a problem. This will definately need more thought.
>

I'm afraid I've confirmed Ty's fears.  The LoginManager patch to fix the
"can't add below root" problem creates a new issue: ownership of objects
within the LoginManager.  I will be asking Ty to make a re-release of 0.8.7
to unpatch part of the patch, but for now, here's a short synopsis of the
problem and how to fix it.

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't
have a good alternative to propose that DC implement.)  The problem is that
once this is done, the LoginManager is no longer "unowned".  To fix this,
add the line:

_owner = UnownableOwner

to the body of the LoginManager class.  This will ensure that even after
_deleteOwnershipAfterAdd(), the LoginManager will remain "unowned".

After you have made this fix and restarted Zope, you may want to "un-own"
any objects contained within your LoginManagers which might have been
created with ownership.  To do this, you should go to each page of each
LoginManager's management interface and copy all objects, then paste them.
Delete the originals, and rename the copies back to their old names.  The
copies will then be "unowned".  You can verify this by checking each
object's management interface: if it is unowned, it will have no
"Ownership" tab.

Why does LoginManager want its contents unowned?  It has to do with the new
security model.  When an executable object is owned, the security machinery
wants to validate that its owner is allowed to do whatever the executable
is doing.  This is great except for the fact that in many sites, the owner
of the LoginManager's objects is actually a user that was retrieved from
that LoginManager.  This means that if LoginManager executes an object to
find out information about a user, and that object is owned by a user from
that LoginManager, infinite recursion and a core dump will swiftly follow.
For this reason, you should make sure that all executable objects in a
LoginManager are either unowned or owned by a user who is *not* supplied by
that LoginManager.  In practice, making sure they're unowned is usually
easier.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] LoginManager add trouble

[Scott Parish]

Using:

Zope2 (cvs)
ZPatterns 0.3.0
LoginManger 0.8.6

When I try to add a LoginManager, I get the following error and traceback.
Any ideas?

sRp

-

Error Type: KeyError
Error Value: _owner

Traceback (innermost last):
  File /a4/srp/Zope2/lib/python/ZPublisher/Publish.py, line 222, in publish_module
  File /a4/srp/Zope2/lib/python/ZPublisher/Publish.py, line 187, in publish
  File /a4/srp/Zope2/lib/python/Zope/__init__.py, line 221, in 
zpublisher_exception_hook
  File /a4/srp/Zope2/lib/python/ZPublisher/Publish.py, line 171, in publish
  File /a4/srp/Zope2/lib/python/ZPublisher/mapply.py, line 160, in mapply
(Object: manage_addLoginManager)
  File /a4/srp/Zope2/lib/python/ZPublisher/Publish.py, line 112, in call_object
(Object: manage_addLoginManager)
  File /a4/srp/Zope2/lib/python/Products/LoginManager/LoginManager.py, line 230, in 
manage_addLoginManager
  File /a4/srp/Zope2/lib/python/OFS/ObjectManager.py, line 249, in _setObject
(Object: ElementWithAttributes)
  File /a4/srp/Zope2/lib/python/AccessControl/Owned.py, line 267, in 
manage_fixupOwnershipAfterAdd
(Object: SheetProviderContainer)
  File /a4/srp/Zope2/lib/python/AccessControl/Owned.py, line 174, in changeOwnership
(Object: SheetProviderContainer)
KeyError: (see above)

-- 
Scott Parish
http://srparish.net

 PGP signature