Hi all,
I'm beginning a project to build a small commercial site for Customer X in Swazoo. It'll be good for me -- the first Swazoo app for me apart from Signal Ground, which was written before most of the core design principles of Swazoo materialized. Signal Ground is, unfortunately, still an app that's bolted rather awkwardly on top of Swazoo. Someday... In any case, this app needs to be able to do these things: - Allow an administrator and several users to login.
I could, in the style of Signal Ground, create one gigantic resource object that handles all of this. But I don't want to repeat that kludge. I'd rather take advantage of some of Swazoo's strengths. In that light, I think I'd do something like this: Site "www.customerX.com"
The Session Resource doesn't need to do too much, but I'm sticking on a couple of points. I think I'll use cookies -- they seem simplest, at this point... and this resource can basically stick a specialized Dictionary (a SwazooSession?) in the environmentData of the inbound request. The resource itself will have to: - keep a dictionary of known sessions
* This is where I'm having problems. Every time a request comes in, I can update the timestamp of the session. But then do I give the resource a thread that periodically expires sessions? I thought these resource thingies were supposed to be unchanging -- everything changing would be somewhere external. Does that mean I should store the sessions in a database? Let's just say that Customer X isn't paying me enough to cover the costs of GemStone/S. Is there another way? I really don't need the sessions stored for longer than 30 minutes or so, so it seems a little silly to put them in a DB in the first place. Perhaps every request could force a session expiration scan? Something about this seems kludgy, too. I may be thinking about this in too general of terms; I should code it for my customer and refactor it later. But I want: a) this to be re-usable; and b) to get some input from some of you web wizards on this problem. Next: the Authorization resource. I would expect it to display a login prompt in a form. It should even be able to appear as if it exists at the same URI as the requested resource (/customer). If the post is successful, then it adds an association like #authorizedName -> 'username' to the session and lets the request continue as if it were a GET on the originally requested resource. The CustomerXFileResource can use this data to determine which directory to display. I would expect this resource to work off of a database of login/password pairs (whether that be stored in a file or a real database). The same resource class could be used for the administrator instance as well as the user instance. The User's file resource is very straightforward, as is the admin resource. Since we can do multipart/form-data posts now, files can be uploaded from within a form. Thanks for any input y'all can provide. :)
Ken |
If you want a cheap object database, look at David Goriseck's OmniBase. I
haven't used it in a real-world app yet (soon though), but it is also the basis of his source code control system for Dolphin, and I've had great success with that. It's fairly minimalist, you'll have to roll your own index services, queries, etc, but I think it would be great for what you're looking at. It has full support for multiple users and transactions, so it would also be great as a shared-state backend for multiple Swazoo servers in a load-sharing situation. He has both VW and Dolphin versions, I believe you're looking at around $100. I am personally thrilled about the product, as a GemStone/S license is far beyond my meager resources (and wouldn't work with Dolphin anyway). You can find it at: http://www.geocities.com/SiliconValley/Software/8887 (Heck, maybe you can trade out an OmniBase license for some non-geocities web space...) As an aside, In my upcoming application I'm planning to sidestep the index and query stuff by using an external index server (probably W2K's) to crawl the objects in the OmniBase database through a Swazoo web interface. Each object will be able to spit out an HTML or XML representation of itself. I can use a unique identifier in the query results to pull the correct object out of the database. Hope this helps in some way. Everything sounds exciting- the session support would be especially welcome. Would there be any chance of pulling the session stuff back into Swazoo? I know commercial projects can sometimes be funky. Jerry Bell [hidden email] -----Original Message----- From: [hidden email] [mailto:[hidden email]]On Behalf Of Ken Treis Sent: Tuesday, November 07, 2000 10:58 PM To: Swazoo-Devel Mailing List Cc: [hidden email] Subject: [Swazoo-devel] Design of a New Swazoo Site Hi all, I'm beginning a project to build a small commercial site for Customer X in Swazoo. It'll be good for me -- the first Swazoo app for me apart from Signal Ground, which was written before most of the core design principles of Swazoo materialized. Signal Ground is, unfortunately, still an app that's bolted rather awkwardly on top of Swazoo. Someday... In any case, this app needs to be able to do these things: - Allow an administrator and several users to login. - Provide a set of files (unique to each user) for download by the user - Allow the administrator to add and remove users - Allow the administrator to upload a file to a user's area I could, in the style of Signal Ground, create one gigantic resource object that handles all of this. But I don't want to repeat that kludge. I'd rather take advantage of some of Swazoo's strengths. In that light, I think I'd do something like this: Site "www.customerX.com" SomeKindOfSessionResource CustomerXFrontPageResource "welcome. Please login as user or admin" AuthorizationResource "on a user list of some sort" CustomerXFileResource "(located at www.customerX.com/customer)" AuthorizationResource "with only one user, the administrator" CustomerXAdministrationResource ""www.customerX.com/admin)" The Session Resource doesn't need to do too much, but I'm sticking on a couple of points. I think I'll use cookies -- they seem simplest, at this point... and this resource can basically stick a specialized Dictionary (a SwazooSession?) in the environmentData of the inbound request. The resource itself will have to: - keep a dictionary of known sessions - attach a known session to each request associated with it - create a new session if the inbound request doesn't have one and attach it - expire old sessions* - show a "session expired" message if somebody tries to use an old session * This is where I'm having problems. Every time a request comes in, I can update the timestamp of the session. But then do I give the resource a thread that periodically expires sessions? I thought these resource thingies were supposed to be unchanging -- everything changing would be somewhere external. Does that mean I should store the sessions in a database? Let's just say that Customer X isn't paying me enough to cover the costs of GemStone/S. Is there another way? I really don't need the sessions stored for longer than 30 minutes or so, so it seems a little silly to put them in a DB in the first place. Perhaps every request could force a session expiration scan? Something about this seems kludgy, too. I may be thinking about this in too general of terms; I should code it for my customer and refactor it later. But I want: a) this to be re-usable; and b) to get some input from some of you web wizards on this problem. Next: the Authorization resource. I would expect it to display a login prompt in a form. It should even be able to appear as if it exists at the same URI as the requested resource (/customer). If the post is successful, then it adds an association like #authorizedName -> 'username' to the session and lets the request continue as if it were a GET on the originally requested resource. The CustomerXFileResource can use this data to determine which directory to display. I would expect this resource to work off of a database of login/password pairs (whether that be stored in a file or a real database). The same resource class could be used for the administrator instance as well as the user instance. The User's file resource is very straightforward, as is the admin resource. Since we can do multipart/form-data posts now, files can be uploaded from within a form. Thanks for any input y'all can provide. :) Ken |
Jerry Bell wrote:
[great info about OmniBase snipped] > Hope this helps in some way. Everything sounds exciting- the session > support would be especially welcome. Would there be any chance of pulling > the session stuff back into Swazoo? I know commercial projects can > sometimes be funky. It does help... I'll have a look at it. And yes, I have every intention of putting the general parts (like sessions and auth) back into Swazoo. That's one of the reasons I got excited about this project. There's little in the Smalltalk code that I'll be writing that is particular to this customer, so I should be able to put most of it right back in. Ken |
In reply to this post by Ken Treis-2
Janko Mivsek wrote:
Thats nice news :) Another Swazoo site is comming ...I'll post the link when it's done. There won't be too much that you'll be able to see without a login, but it'll be a good reference in case you have to give another presentation. :) I am thinking about security/session control for a while,The only problem I have with that approach is that you have to write a authentication mechanism that fits the entire site. In the case of this site: - one part (the front page) is accessible to everyone - one part (the admin) is accessible to only one person - the remaining parts (the user areas) are accessible to only the user who "owns" the area The Swazoo framework of building up composites makes it easy to put an auth resource into the tree above the sensitive areas. I remember us talking about this at CS1 -- it's what makes the Resource tree so cool. I would introduce a session atribute to a HTTPRequest, and aThis sounds like what I described.. though a Session object would be little more than a fancy dictionary. That way, sites can use them however they want to. There would be room for all the timestamps you could ever want, an id string, user info, user variables, and more. I personally like sticking the session in the environmentData portion of a Request (which exists today). That way, sites that don't require sessions don't have to carry one around. We could even add "cheater" accessors like: session
session: aSession
User variables are thoseI played with that idea a little (SessionManager with a expiration thread), but I don't quite understand how it would work for a server hosting multiple sites. You know more about this than I do, but it seems obvious to me that sessions are rarely carried across sites. Do you use separate session dictionaries for each site? As for security management, I'm still not sure how this would handle the case I described. Would you mind taking the time to explain it to me? I need some sort of authentication that works like this: Username Password (Directory)
Obviously, I can infer the directory from the username. But until they're logged in, they can't see their directory. They can't upload anything; just download. I also need something like this: admin theMan (all + ACL editing) ... and in this case, the administrator needs to have access to all of the directories, upload permissions in each directory, and the ability to edit the list of users/passwords. How would you go about solving this problem? I have no doubt that you've done something similar already. Therefore Sesion/Security is a service for all resources inI don't quite understand what you're getting at here.. but it's late and I've been turning the crank on an apple press (making homemade cider.. yum) all evening. So it's probably me, not you. :) On the one hand, you say that security is for the whole site; on the other, you'd do it on a resource level? Maybe I'm missing something. I know I know, this is the way very similar to AIDA :) ButOne thing we'll need for this (standard HTTP way) is a base64 encoding / decoding stream. I think the SRP project has one. Anybody want to follow up? About database. OmniBase is more and more interesting choiceI'll have a look at it. I've also thought of developing some sort of PersistentOrderedCollection (and PersistentDictionary) to use as a makeshift database. They'd BOSS out (or smart ref stream in Squeak, IIRC) their affected members whenever they got an #at:put: and use weak dictionaries for caching. <PLEA>Don't bash this just yet, people, I haven't thought it through all the way... :) I plead the cider excuse again (see above). The stuff's not even fermented yet...</PLEA> RegardsThanks for the follow-up.. I appreciate your insights. ----
|
In reply to this post by Ken Treis-2
At 11:03 PM 11/8/2000 -0800, Ken Treis wrote:
>One thing we'll need for this (standard HTTP way) is a base64 encoding / >decoding stream. I think the SRP project has one. Anybody want to follow up? I believe there's one as part of the Postgres EXDI driver. |
Free forum by Nabble | Edit this page |