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

2000-06-02 Thread Evan Simpson

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


___
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-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 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-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]>
> 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 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.

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




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 Itamar Shtull-Trauring

"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?

-- 
Itamar S.T.  [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] Problems with LoginManager form-based login

2000-05-24 Thread Phillip J. Eby

At 01:47 PM 5/24/00 +0300, Itamar Shtull-Trauring wrote:
>I add a folder, with a LoginManager in it, define Cookie Auth as only
>authntication.  Now, every time I try to view the folder I get the loginForm
>asking me to login, even though Anonymous has permissions to view the
>pages.  If I delete the loginForm this doesn't happen, I can view the page
>with no problems.
>
>How do I get the loginForm to appear only if the user doesn't have enough
>permissions?
>

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.

(Details of the problem: manage_workspace is set up only to require the
"Anonymous" role, but then it checks whatever user is logged in for
permissions to display management tabs.  If LoginManager were to allow
Anonymous access just because the URL being hit allowed Anonymous access,
manage_workspace would deny access to the page.  Worse, it would deny it by
popping up a basic authentication dialog.  We know this because an early
version of LoginManager seemed bizarrely broken until we dug through enough
Zope code to find out what was going on, and changed LoginManager to do
what user folders do: only log in the anonymous user if you're the root
acl_users folder.)


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