On Sat, 2003-03-01 at 23:32, Matt Feifarek wrote:
> If we were to use a separate User/user validation class/process, it
> would be tricky to make it still work in a general way (which it would
> have to be if it were in stock page.py). I know that you don't like that
> idea, but that's how we do it now, so maybe I can't get outside of my box.
Well, here's how I'd imagine it going:
* Your class raises AuthorizationRequired
* Page catches that, and displays the login page
(where the login page comes from, especially so that its look can be
changed, I don't know -- that's currently my sticking point)
* The login page uses _action_loginUsername and _action_loginPassword
field names. All other fields in the request are in the form as
* When submitted, Page notices those special fields in awake(). It
calls the actionLogin method.
* actionLogin can be overridden entirely, but probably a default
implementation will work for most people, with actionLogin calling
the verifyUsernameAndPassword function. If the login fails, it
presents an error message and gives them the login page again.
* Assuming login is successful, actionLogin gets the userID of the new
user (from some other pluggable function, userIDForUsername).
* That userID is put in the session.
* Page has a user() method, which returns the user object (based on the
userID and some pluggable class) or None if not logged in.
So your average secure page would look like:
def awake(self, trans):
if self.user() is None: raise AuthorizationRequired
In your SitePage, you might add a method or class variable like
"secure", which would cause this "self.user() is None" test to be done
How exactly you provide your own user class and those select functions
for logging in, I'm also not sure. Maybe in your SitePage you'd add
from lib.MyUserClass import MyUserClass
userClass = MyUserClass
Or maybe you actually give the module, which is expected to contain a
User class and some specifically named functions.