Re: [Zope-dev] Problems with LoginManager form-based login

2000-05-28 Thread Phillip J. Eby

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.


___
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] Problems with LoginManager form-based login

2000-05-26 Thread Stuart 'Zen' Bishop

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

 Meanwhile, I suppose Ty and I should try to come up with a proposal for
 revising ZPublisher to be able to walk back on the user lookups but still
 use the login form closest to the URL being accessed.

-- 
Stuart Bishop  Work: [EMAIL PROTECTED]
Senior Systems Alchemist   Play: [EMAIL PROTECTED]
Computer Science, RMIT


___
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] Problems with LoginManager form-based login

2000-05-26 Thread Evan Simpson

- Original Message -
From: Phillip J. Eby [EMAIL PROTECTED]
 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


___
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] Problems with LoginManager form-based login

2000-05-26 Thread Phillip J. Eby

At 03:05 PM 5/26/00 -0400, Evan Simpson wrote:
- Original Message -
From: Phillip J. Eby [EMAIL PROTECTED]
 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.


___
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] Problems with LoginManager form-based login

2000-05-26 Thread Evan Simpson

- Original Message -
From: Phillip J. Eby [EMAIL PROTECTED]
 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


___
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] Problems with LoginManager form-based login

2000-05-24 Thread Phillip J. Eby

At 05:24 PM 5/24/00 +0300, Itamar Shtull-Trauring wrote:
"Phillip J. Eby" wrote:

 Make your root acl_users a LoginManager, with the loginForm there.
 LoginManager will only allow "Anonymous" to log in if it is the root
 acl_users.  This is how standard user folders behave, and *have to* because
 of the way manage_workspace works, unfortunately.  Until/unless a new login
 protocol is worked out in Zope, this is the workaround.

But this user isn't even supposed to access manage_workspace - I just need
it to access a PTK join_form so it can become a member.  

I tried making loginForm on the top level display a dtml method
customLoginForm (which contains the actual form), and then override it in
the PTK folder, but it doesn't - it displays the one on the top level.  And
I can't use the same loginForm in the whole site, because I may have  few
portals, and I need the login form to say "if you are not a member you can
join here".

Any ideas?



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.

Meanwhile, I suppose Ty and I should try to come up with a proposal for
revising ZPublisher to be able to walk back on the user lookups but still
use the login form closest to the URL being accessed.


___
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] Problems with LoginManager form-based login

2000-05-24 Thread Kevin Dangoor

- Original Message -
From: "Phillip J. Eby" [EMAIL PROTECTED]
To: "Itamar Shtull-Trauring" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, May 24, 2000 9:59 AM
Subject: Re: [Zope-dev] Problems with LoginManager form-based login


 Make your root acl_users a LoginManager, with the loginForm there.
 LoginManager will only allow "Anonymous" to log in if it is the root
 acl_users.  This is how standard user folders behave, and *have to*
because
 of the way manage_workspace works, unfortunately.  Until/unless a new
login
 protocol is worked out in Zope, this is the workaround.

Can you make the root acl_users a LoginManager now? (Is that in 2.1.6 or the
CVS version?) I know that the new ownership stuff made this impossible to do
in the CVS version (unless that's already been changed...)

Kevin


___
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 )