Re: [Zope-dev] Problems with LoginManager form-based login
At 07:11 PM 5/26/00 +1000, Stuart 'Zen' Bishop wrote:
On Wed, 24 May 2000, Phillip J. Eby wrote:
This is a problem that apparently can only be solved by replicating ZPublisher's backward walk, which is the wrong thing to do because the traversal will be O(n^2). Bleah. I guess we'll have to do something like Stuart Bishop's backward walk in the GUF, since any enhancement of the ZPublisher architecture to handle login forms properly won't happen until at least 2.2.
The backward walk stuff (which I don't think ever worked - every time I fixed one case it seemed I'd break another) has been torn out and replaced with code that does what you are after. Grab a copy of the latest version and search for 'WooHoo' in GenericUserFolder.py
Been there, done that. Yours doesn't work either, btw. Well, actually, it does, it's just that it causes a memory leak because it leaves an unintended circular reference. We've got a version that fixes the circular reference, but in a really really ugly way (it does a run-time patch to BaseRequest.close() to remove the poked-in unauthorized() method). It will be in LM 0.8.6, which we're trying to finish now. We might have had it done today, but there was a bomb threat in one of the buildings in the complex where we work and we were evacuated for a couple hours. LM 0.8.6 also works with Zope 2.2 as far as being able to be added, although I'm not sure it interoperates properly with the new security API. It will still be backward compatible with Zope 2.1.6 either way, though.
----- Original Message ----- From: Phillip J. Eby <pje@telecommunity.com>
Been there, done that. Yours doesn't work either, btw. Well, actually, it does, it's just that it causes a memory leak because it leaves an unintended circular reference. We've got a version that fixes the circular reference, but in a really really ugly way (it does a run-time patch to BaseRequest.close() to remove the poked-in unauthorized() method).
The GUF version, at least, doesn't need this drastic a fix. Adding the following line to the top of guf_unauthorized should suffice: del request.RESPONSE.unauthorized Cheers, Evan @ digicool & 4-am
At 03:05 PM 5/26/00 -0400, Evan Simpson wrote:
----- Original Message ----- From: Phillip J. Eby <pje@telecommunity.com>
Been there, done that. Yours doesn't work either, btw. Well, actually, it does, it's just that it causes a memory leak because it leaves an unintended circular reference. We've got a version that fixes the circular reference, but in a really really ugly way (it does a run-time patch to BaseRequest.close() to remove the poked-in unauthorized() method).
The GUF version, at least, doesn't need this drastic a fix. Adding the following line to the top of guf_unauthorized should suffice:
del request.RESPONSE.unauthorized
You're making the assumption that unauthorized gets called. If it doesn't get called (because the current user *does* exist in a higher-level folder), then the hook will never get released.
----- Original Message ----- From: Phillip J. Eby <pje@telecommunity.com>
The GUF version, at least, doesn't need this drastic a fix. Adding the following line to the top of guf_unauthorized should suffice:
del request.RESPONSE.unauthorized
You're making the assumption that unauthorized gets called. If it doesn't get called (because the current user *does* exist in a higher-level folder), then the hook will never get released.
D'oh! How 'bout if REQUEST.close() were to always do a self.__dict__.clear()? Cheers, Evan @ digicool & 4-am
At 06:14 PM 5/26/00 -0400, Evan Simpson wrote:
D'oh! How 'bout if REQUEST.close() were to always do a self.__dict__.clear()?
Are you absolutely positively sure that REQUEST.response is never accessed following REQUEST.close()? In my cursory examination of the code paths, I wasn't sure that could be definitively said.
----- Original Message ----- From: Phillip J. Eby <pje@telecommunity.com>
At 06:14 PM 5/26/00 -0400, Evan Simpson wrote:
D'oh! How 'bout if REQUEST.close() were to always do a self.__dict__.clear()?
Are you absolutely positively sure that REQUEST.response is never accessed following REQUEST.close()? In my cursory examination of the code paths, I wasn't sure that could be definitively said.
I confirmed with Jim that REQUEST.close() is the final allowable access to REQUEST. On the other hand, his new ideas on authenticating may make this all moot. Cheers, Evan @ digicool & 4-am
In previous versions of Zope, it was possible to do "setuid" code by setting AUTHENTICATED_USER to a new user, then resetting when code completed. Zope 2.2 loses this ability, as it has absolutely no API for setting or stacking the "current user", without completely replacing the ZopeSecurityPolicy. This is problematic for things like GUF and GUS which want to execute certain through-the-web objects *as* a particular user. Not as a mask between that user and the current user, but *as* that user, because the object is in the process of finding out what roles the logging-in user has. Currently, it would seem the only way to do this in bounds of the current ZopeSecurityPolicy is to poke into getSecurityManager()._context.user, which seems like a bad idea. There is already a getUser() method on the SecurityManager; Should there perhaps be a setUser() (or _setUser()) method as well?
"Phillip J. Eby" wrote: [...]
LM 0.8.6 also works with Zope 2.2 as far as being able to be added, although I'm not sure it interoperates properly with the new security API. It will still be backward compatible with Zope 2.1.6 either way, though.
Hmmm ... just tried it on a fresh (Thursday) CVS dump, and get a no-go: Error Type: KeyError Error Value: _owner Traceback (innermost last): File /home/web/ActiveBoise/Games/lib/python/ZPublisher/Publish.py, line 224, in publish_module File /home/web/ActiveBoise/Games/lib/python/ZPublisher/Publish.py, line 189, in publish File /home/web/ActiveBoise/Games/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook File /home/web/ActiveBoise/Games/lib/python/ZPublisher/Publish.py, line 175, in publish File /home/web/ActiveBoise/Games/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_addLoginManager) File /home/web/ActiveBoise/Games/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_addLoginManager) File /home/web/ActiveBoise/Gaming/lib/python/Products/LoginManager/LoginManager.py, line 230, in manage_addLoginManager File /home/web/ActiveBoise/Games/lib/python/OFS/ObjectManager.py, line 249, in _setObject (Object: ElementWithAttributes) File /home/web/ActiveBoise/Games/lib/python/AccessControl/Owned.py, line 267, in manage_fixupOwnershipAfterAdd (Object: SheetProviderContainer) File /home/web/ActiveBoise/Games/lib/python/AccessControl/Owned.py, line 174, in changeOwnership (Object: SheetProviderContainer) KeyError: (see above) -->
At 01:51 AM 6/2/00 -0600, Bill Anderson wrote:
"Phillip J. Eby" wrote:
[...]
LM 0.8.6 also works with Zope 2.2 as far as being able to be added, although I'm not sure it interoperates properly with the new security API. It will still be backward compatible with Zope 2.1.6 either way, though.
Hmmm ... just tried it on a fresh (Thursday) CVS dump, and get a no-go:
Error Type: KeyError Error Value: _owner
Thanks for the heads-up, but it worked with the current CVS as of the release of 0.8.6. It's going to be a little while before we can take a whack at it again. 2.1.6 is our primary development platform for both ZPatterns and LoginManager. When we do releases, we check them against the latest CVS of Zope for compatibility, but it's something of a pain as we have to do a certain amount of conditional coding to deal with the presence or absence of 2.2 API's. This is more a problem with LoginManager, although ZPatterns is about to have some conditional code added to work with Jim's new __get/set/delattr__ support (which, if it works, would mean the DynPersist module would not be required for 2.2).
participants (3)
-
Bill Anderson -
Evan Simpson -
Phillip J. Eby