[Zope-PTK] password policy change interface

Bill Anderson bill@libc.org
Thu, 07 Sep 2000 00:46:52 -0600


Chris Withers wrote:
> 
> Bill Anderson wrote:
> > Whaddya think of that?
> 
> *grinz* I'm enjoying playing the stoopid person today (yes, yes, I know
> ' I do it so well' ;-)

Typecasting. Blame it on the casting agent. ;^)=

> 
> Well, in that role, what would really help me was a description of the
> interfaces the policy object exposes and how they differ from the ones
> provided by the PTK equivalent object.
As soon as I have them all worked out ;)

> 
> Then everyone can compare and see which they think is right...

IMO, things dealing with authentication should _not_ be defined by the PTK. That is the realm of user management, which
the PTK is not (AIUI) aimed at doing. It has the current default setup now mainly out of (AIUI) a need to have
_something_ to do it.

Basically, there are only a few variations on your basic portal. Authentication policies a few more. Add them together
and .. dman that's  alot of permutations. By leaving authentication policies to the user management tool, you keep the
basic PTK simple, as it should be.
 
The PTK itsself should basically, IMO, call things like 'authenticate_User', 'logout_User', perhaps even 'get_User'.
Anything that deals with user authentication should no tbe implemented in the PTK. do this and you get conflict and
confusion (witness the 'Desktop backgroun' control conflict when using Enlightenment and GNOME. Someone has to give).

What should be done, is that the PTK calls a predefined User Management API. The default implementation of PTK Demo
(remember, it is just that, a demo) should come with some sort of "Zope User Management API" that abides by the ZUMAPI.

That's part of why I never liked the name of PTK; it didn't match the common uses of it as implemented. Let's face
reality, PTKDemo is not a "Portal Site" as implemented, but rather a "Community Site".

<dtml-plug type=shameless>
See my Wiki for further details. Soon I hope to have more details on those put on zope.org.
</dtml-plug>

Now, as to what that API should look like, that's an entirely different animal. I have some ideas though. Perhaps a
Proposal could be written, as soon as I get the time.

just some off the cuff ideas:

authenticate_User
Used for user log in. Returns Success or Failure

logout_User
Used to log the user out. Likely returns a redirect url.

get_User
Used when you need the user object (useful or not?), and returns the object itsself. (What about SQL-Authed Users?)

get_UserPage
Used ot get the user's URL if any. In Community sites that implement a Member Folder (such as PTKDemo), it would return
the URL to the User's Folder. In sites that don't it can return the URL to their 'Profile Page' or whatever stands in
place (maybe a redirect or something). Returns a URL.

mail_UserPassword
Here is the tricky one, but only for what it returns. The UMP would do the work, and should return a URL, or an actual
page fo rth euser to see.


Then, a User Management Product would implement the behind the scenes methods to return the required result.

Ideas? Suggestions, other than checking into the local State Hospital (Looney Bin).

Bill.




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