From: Ian B. <ia...@co...> - 2003-02-28 08:47:43
|
I'm planning on reimplementing an old program, and I thought "oh, I'll use users, maybe I'll play around with generalizing the user management." Just the words going through my mind, yep... Then I thought about how I'd implement it, and I quickly realized that I'd implement it as a wrapper around a database row. I'd wrap it in SQLObject so that it would interact well with my other database objects -- if I was using MK I'd want it to be an MK object, or a ZODB object, or whatever. This is *very* important to me, I don't want some crappy user object that's so generic it doesn't work well with my other objects. Users are usually closely tied to everything else in the application. Okay, so we have different backends, like UserKit does currently. So, what does the frontend do? And I realized... almost nothing. Users have an ID, and they probably have a username, password, email, and name. Not complex stuff. My user objects *will* be complicated, but they will be complicated by all sorts of stuff that is application-specific. And what would I gain by using a user framework? I guess I'd save about 10 lines of code for the username and such... at the expense of 15 lines of code for the glue. Maybe some reusable pages could be made... but what, a login, password change, forgotten password, user profile editing... not big stuff. So I've pretty much entirely unsold myself on doing a UserKit, or fleshing UserKit, or pushing its use. That said, there's some useful stuff we can do to make users easier to implement. Particularly making logins and authentication easier. A sample implementation of users would also probably be helpful. Some conventions for accessing the logged-in user would be good. Lots of little details. Ian |
From: Chuck E. <Chu...@ya...> - 2003-02-28 09:56:56
|
On Friday 28 February 2003 12:48 am, Ian Bicking wrote: > Okay, so we have different backends, like UserKit does currently. > So, what does the frontend do? And I realized... almost nothing. > Users have an ID, and they probably have a username, password, email, > and name. Not complex stuff. My user objects *will* be complicated, > but they will be complicated by all sorts of stuff that is > application-specific. ...which would go in a subclass that inherits UserKit.User. It's okay to inherit a generic class and add app specifics. It's easy, too. > And what would I gain by using a user framework? I guess I'd save > about 10 lines of code for the username and such... at the expense of > 15 lines of code for the glue. Maybe some reusable pages could be > made... but what, a login, password change, forgotten password, user > profile editing... not big stuff. Those starter pages can be a bore to trudge through when starting fresh projects. If UserKit provided out of the box: - login panel - registration - including optional required confirmation, or optional cancellation - password change - lost password (forgotten or reset) - profile editing then that gets the developer up and running that much quicker. UserKit could be a slice of "postnuke" without turning into a sprawling monolith of gadgets. > So I've pretty much entirely unsold myself on doing a UserKit, or > fleshing UserKit, or pushing its use. Awww. :-( > That said, there's some useful stuff we can do to make users easier > to implement. Particularly making logins and authentication easier. > A sample implementation of users would also probably be helpful. Ahem. UserKit could itself be a sample implementation of users right? And we could put a little example application in there. "MiniBlogger" > Some conventions for accessing the logged-in user would be good. > Lots of little details. I intended the methods in UserKit, including their names, params and docstrings to provide those conventions. That was the point of making some of those abstract classes! (which passed through this list before going into cvs, btw) I was surprised by this last part that you wrote. If you plan on providing "some useful stuff...to make users easier to implement" what form would that take, if not a Kit? If a sample application, how about pushing most of the user management up into the Kit so that developers with similar requirements can hit the ground running? I'll do this myself someday if no one gets to it first, but I want to do it in the context of a new, real application. (I always end up with better frameworks that way.) BTW UserKit *is* used in a production application at HFD.com. Just in case anyone thought it was total vapor. :) Ian, for code slingers like us, cranking out users *is* pretty easy, but a finished UserKit would be faster still and benefit the Webware community. Of course, your time is your own as always. I'm just emphatic that there *are* good reasons to have a prod-quality, complete UserKit with sample app. -- Chuck http://ChuckEsterbrook.com |
From: Matt F. <ma...@da...> - 2003-02-28 19:21:17
|
Chuck Esterbrook wrote: >Those starter pages can be a bore to trudge through when starting fresh >projects. If UserKit provided out of the box: > - login panel > - registration > - including optional required confirmation, or optional cancellation > - password change > - lost password (forgotten or reset) > - profile editing > We've got some of that running in something we call "UserAccountKit". It's not so focussed on the creation and modification of profiles, since we handle that on intranet pages, but it does provide the login panel, cookie-management, and methods for servlet security tests. It's shoehorned into a servlet via a mixin inheritance deal; the idea is that SecurePage can be inherited from instead of Page.py (just like the Ww example, only more sophisticated). It's not great, but we'd be happy to share it with the group to try and get a more general purpose Kit going. Right now, it's basically: - a SecurePage.py that handles state via session, and provides for the various messages related to logging in and setting cookies etc. - User.py -- a class that is a basic framework for a User (just a container, really) - UserValidator.py -- a class that attempts to make a User() given login information. Ours checks against a ORM database via an external class; it can be modified to check against anything There's also a bunch of templates for making new accounts and groups and assigning permissions and stuff, but it's all based around that ORM'd accounts database, so it won't be generally useful. One thing that we do that might be annoying for people is to expand actions() into read_actions(), write, delete... methods are thusly categorized, and thereby a user's permissions are checked before application logic runs. FYI... |
From: Chuck E. <Chu...@ya...> - 2003-02-28 20:20:37
|
Hey Matt, This certainly sounds like interesting work! I'm creating a "Webware Sandbox" where everyone and his brother has CVS write access and can upload their code into a directory with their name. (Ian Bicking suggested this.) The Sandbox would make it easy for us to share code, get feedback, etc. without the delays in considering what should go into Webware-proper and what shouldn't. It would also be nicer to type "cvs upd" to get everyone's fixes and refinements vs. rummaging through emails and attachments. I applied for a SourceForge project for this last night. I'll announce when we get it or look for another solution if we don't. My point is you could upload all your "shareables" there. I'll certainly be uploading several of mine. -Chuck On Friday 28 February 2003 11:22 am, Matt Feifarek wrote: > Chuck Esterbrook wrote: > >Those starter pages can be a bore to trudge through when starting > > fresh projects. If UserKit provided out of the box: > > - login panel > > - registration > > - including optional required confirmation, or optional > > cancellation - password change > > - lost password (forgotten or reset) > > - profile editing > > We've got some of that running in something we call "UserAccountKit". > It's not so focussed on the creation and modification of profiles, > since we handle that on intranet pages, but it does provide the login > panel, cookie-management, and methods for servlet security tests. > > It's shoehorned into a servlet via a mixin inheritance deal; the idea > is that SecurePage can be inherited from instead of Page.py (just > like the Ww example, only more sophisticated). > > It's not great, but we'd be happy to share it with the group to try > and get a more general purpose Kit going. > > Right now, it's basically: > > - a SecurePage.py that handles state via session, and provides for > the various messages related to logging in and setting cookies etc. - > User.py -- a class that is a basic framework for a User (just a > container, really) > - UserValidator.py -- a class that attempts to make a User() given > login information. Ours checks against a ORM database via an external > class; it can be modified to check against anything > > There's also a bunch of templates for making new accounts and groups > and assigning permissions and stuff, but it's all based around that > ORM'd accounts database, so it won't be generally useful. > > One thing that we do that might be annoying for people is to expand > actions() into read_actions(), write, delete... methods are thusly > categorized, and thereby a user's permissions are checked before > application logic runs. > > FYI... > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss -- Chuck http://ChuckEsterbrook.com |
From: Ian B. <ia...@co...> - 2003-02-28 21:45:06
|
On Fri, 2003-02-28 at 03:56, Chuck Esterbrook wrote: > On Friday 28 February 2003 12:48 am, Ian Bicking wrote: > > Okay, so we have different backends, like UserKit does currently. > > So, what does the frontend do? And I realized... almost nothing. > > Users have an ID, and they probably have a username, password, email, > > and name. Not complex stuff. My user objects *will* be complicated, > > but they will be complicated by all sorts of stuff that is > > application-specific. > > ...which would go in a subclass that inherits UserKit.User. It's okay to > inherit a generic class and add app specifics. It's easy, too. But it's harder than reimplementing all of UserKit! Especially in terms of understanding other non-trivial code. > Those starter pages can be a bore to trudge through when starting fresh > projects. If UserKit provided out of the box: > - login panel > - registration > - including optional required confirmation, or optional cancellation > - password change > - lost password (forgotten or reset) > - profile editing Registration and profile editing are both usually application-specific. I *would* like to have a login built into Webware (WebKit, actually), and password management would be easy enough too. > > That said, there's some useful stuff we can do to make users easier > > to implement. Particularly making logins and authentication easier. > > A sample implementation of users would also probably be helpful. > > Ahem. UserKit could itself be a sample implementation of users right? > And we could put a little example application in there. "MiniBlogger" A sample implementation isn't the same as reusable code. There'd be no expectation that people would all use those sample classes -- the classes would suffice for applications with simple user requirements, and they wouldn't try to include the flexibility to be appropriate for all people. > > Some conventions for accessing the logged-in user would be good. > > Lots of little details. > > I intended the methods in UserKit, including their names, params and > docstrings to provide those conventions. That was the point of making > some of those abstract classes! (which passed through this list before > going into cvs, btw) Well, I wasn't here for that discussion, so I'm not bound ;-) > I was surprised by this last part that you wrote. If you plan on > providing "some useful stuff...to make users easier to implement" what > form would that take, if not a Kit? It would be a standard interface, with hooks included in *WebKit* to handle that interface. All we need to standardize users is make a simple interface description. For instance, a user object should have these methods: userID, username, setUsername (but userID can't be changed), email, setEmail, firstName, setFirstName, lastName, setLastName, verifyPassword, setPassword There may also be some functions, like verifyUsernameAndPassword, UsernameInvalid exception... probably some others that I'm forgetting. That could be implemented by any class with any implementation. People could provide implementations or frameworks for several backends, but the only requirement is the interface. Maybe we could provide a base class that has some helper methods for these. It would be one module, but I suppose you could call it UserKit. Then we add some stuff to WebKit -- I think it should be added directly to Page -- to set up a good login system, as well as some hooks for permission. I'd say we should do this by putting in more support for exceptions, and catching HTTPAuthorizationRequired and HTTPForbidden, and turning these into login screens or permission denied screens. I don't think it should be part of a separate SecurePage class, because everyone adds this functionality to their application eventually. Ian |
From: Matt F. <ma...@da...> - 2003-03-01 17:58:09
|
Ian Bicking wrote: >Registration and profile editing are both usually application-specific. >I *would* like to have a login built into Webware (WebKit, actually), >and password management would be easy enough too. > > That's consistent with our experience with our own "UserAccountKit" >Then we add some stuff to WebKit -- I think it should be added directly >to Page -- to set up a good login system, as well as some hooks for >permission. I'd say we should do this by putting in more support for >exceptions, and catching HTTPAuthorizationRequired and HTTPForbidden, >and turning these into login screens or permission denied screens. > >I don't think it should be part of a separate SecurePage class, because >everyone adds this functionality to their application eventually. > > I can't agree with that. Only a portion of our Webware applications require security; most of the servlets we run are for publicly available sites, and security just isn't necessary. It should definitely be optional. Sure, you could turn it off by setting a method like thisPageNeedsSecurity() but that doesn't seem like the traditional way. > > |
From: Luke O. <lu...@me...> - 2003-03-01 18:47:26
|
Hmm. My thoughts (also from our own homebrew User/SecurePage derivations): > I can't agree with that. Only a portion of our Webware applications > require security; most of the servlets we run are for publicly available > sites, and security just isn't necessary. It should definitely be optional. > > Sure, you could turn it off by setting a method like > thisPageNeedsSecurity() but that doesn't seem like the traditional way. We have a SecurePage, a LoginPage, and a RoleMixin (which is almost always mixed with SecurePage at the commone level). Any page which requires a user to login ultimately derives from the SecurePage. Some of our sites use a simple SQL query-based method of implementing users, others use ORM User and Role objects. Because of this variance, SecurePage+RoleMixin provide a common interface at the Page level for getLoggedInUser() and userHasRole(user, role). For most of these pages, users must be logged in. However, we have a simple flag method (as you describe...requiresValidUser()) for pages that have both a public display and user-specific display. Just thoughts for the mill. Nothing very different from the SecurePage example. - Luke ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ |
From: Ian B. <ia...@co...> - 2003-03-01 19:53:39
|
On Sat, 2003-03-01 at 11:59, Matt Feifarek wrote: > >I don't think it should be part of a separate SecurePage class, because > >everyone adds this functionality to their application eventually. > > > I can't agree with that. Only a portion of our Webware applications > require security; most of the servlets we run are for publicly available > sites, and security just isn't necessary. It should definitely be optional. Certainly the security should be optional, but I don't see any reason why the hooks have to be in a separate class. I'd either expect there to be a method (like .secure()) that would tell if the page should require a login, but probably better would be if you raise a particular exception at any point you'll get a login. There wouldn't be any overhead if you didn't use it, but it would be there when you needed it. It also doesn't force you to make a page public or not public -- a page could be public sometimes and private others. The SecurePage style doesn't allow that, and I don't really see any benefits to SecurePage (besides simplifying Page, but I don't think that's a big deal). Ian |
From: Matt F. <ma...@da...> - 2003-03-02 05:30:40
|
Ian Bicking wrote: >there when you needed it. It also doesn't force you to make a page >public or not public -- a page could be public sometimes and private >others. The SecurePage style doesn't allow that, and I don't really see > > That's a very good point. 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. |
From: Ian B. <ia...@co...> - 2003-03-02 06:02:04
|
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 hidden variables. * 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: class SomeSecurePage(Page): def awake(self, trans): Page.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 automatically. 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 something like: from lib.MyUserClass import MyUserClass class SitePage(Page): userClass = MyUserClass Or maybe you actually give the module, which is expected to contain a User class and some specifically named functions. Ian |
From: Frank B. <fb...@fo...> - 2003-02-28 10:03:47
|
Hi, Ian Bicking schrieb: > Okay, so we have different backends, like UserKit does currently. So, > what does the frontend do? And I realized... almost nothing. Users > have an ID, and they probably have a username, password, email, and > name. Not complex stuff. UserKit tried to solve some more problems. Reading the old mails it seems, counting users (like "There are 3 guests and 1 registered user online") was important as well. To me info like this is completely irrelevant. Preference editing and persistence is important, though. Also preference tracking ("this customer likes books by Stephen King") is interesting, but as you said, this stuff is very application dependent and I'd rather not see this in a UserKit-NextGeneration. OTOH Role management is a valid point in UserKit. Sooner or later you're going to need this. > And what would I gain by using a user framework? I guess I'd save about > 10 lines of code for the username and such... at the expense of 15 lines > of code for the glue. Maybe some reusable pages could be made... but > what, a login, password change, forgotten password, user profile > editing... not big stuff. > > So I've pretty much entirely unsold myself on doing a UserKit, or > fleshing UserKit, or pushing its use. > > That said, there's some useful stuff we can do to make users easier to > implement. Particularly making logins and authentication easier. A > sample implementation of users would also probably be helpful. Some > conventions for accessing the logged-in user would be good. Lots of > little details. In my Wiki I currently use a global DataTable-ParamFactory (called CsvUserManager) as user storage. My solution is very crude and doesn't allow removing or changing users. But it's better than having user/password pairs in the source code, like SecurePage currently has. I absoluetly agree, that a simple user managemenent with authentication, profile and password management would help development of websites with Webware a great deal. SecurePage just is not general enough. I also think, that the interface of UserKit might be a good start for this. ciao -- Frank Barknecht |
From: Michael E. <men...@ka...> - 2003-02-28 13:24:52
|
> UserKit tried to solve some more problems. Reading the old mails it > seems, > counting users (like "There are 3 guests and 1 registered user > online") was Yeah, I find that stuff irrelevant as well. That's useful if you're building a forum type application but not for much else as far as I can see. One thing that I just ran into which I think would be useful would be to have preferences that allow different display information. More of a hierarchy so that if you had a role hierarchy like: Owner Manager SalesRep You could allow the owner role full access, the manager role a little less access and the salesrep role basic access all of which would "cloak" certain navigation and pages depending on the users role. I ended up writing my own and was hoping to use UserKit but it really didn't have much functionality that I could plug-in to an existing system. I have to refactor mine because it's not the most flexible design and requires some manual tasks for preference editing. Mike |
From: Frank B. <fb...@fo...> - 2003-03-02 09:47:29
|
Hallo, Ian Bicking hat gesagt: // Ian Bicking wrote: > Well, here's how I'd imagine it going: > > * Your class raises AuthorizationRequired I'd just like to point out, that in a lot of applications Pages do not *require* login, but provide it as a service. For example slashdot.org doesn't have "AuthorizationRequired" but offers advanced customization to registered and logged-in users. Most of the times in these kinds of apps, the "LoginPage" isn't a real Page, but a LoginBox as a part of the Page. This seems to not fit well with exceptions, because the LoginBox is not the result of an exception occuring in the Page, it's normal behaviour. But this is just a feeling, probably exceptions can be made to handle the AuthorizationPossible case as well. ciao -- Frank Barknecht _ ______footils.org__ |
From: Ian B. <ia...@co...> - 2003-03-02 10:06:49
|
On Sun, 2003-03-02 at 03:46, Frank Barknecht wrote: > > * Your class raises AuthorizationRequired > > I'd just like to point out, that in a lot of applications Pages do > not *require* login, but provide it as a service. I didn't address it there, but it would be fairly easy. The login page would embed a small form -- username and password -- that would set _action_loginUsername/_action_loginPassword. This form would be available (via some method) to any page, and so could be embedded anywhere -- or you could make your own form, just making sure to use those field names, and setting the action appropriately (i.e., to the page they are currently visiting). Ian |