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

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

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,
also trying to understand your way with
SessionResources/Authentication resources, but I still don't
get in :) IMHO, the simplest way is to put Session/Security
in separate objects and tight them to the Site resource,
therefore all resources of one Site can use security
services.

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 a
WebSession instance for each session would hold all session
related info, such as timestamps (created, last accessed),
session id, user info (a separate WebUser object) and
enviromental info (user variables).

This 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
    ^self environmentAt: #session ifAbsent: [nil]

session: aSession
    self environmentAt: #session put: aSession
 

User variables are those
whose scope is all resources for that session. Like global
variables, but limited to particular session. Session user
variables are very very helpful by our AIDA experiences in
many ocasions.

So, we can introduce something like SessionManager with a
list of all sessions, and a SecurityManager with all
registeres users/groups. About expiration of sessions, This
can be a responsibility of SessionManager. There can be a
thread, which periodicaly go through sessions and remove
inactive ones. That's AIDA way to do, but we actually don't
delete sessions, just deactivate them (move from in-memory
cache to database). But, that way you can do anything you
like.

I 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)
ken         secure      ken
joe         GSIsFun     joe
janko       3r4n0v4     janko

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 in
particular Site, regardles if they need it or not.
HTTPRequest is a way to carry Session/Security info. I would
introduce SecureResource, which would have one more
attribute: acl: Access Control List. SecureResource's
responsibility would then be to test, if some action is
granted or not.

I 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 :) But
it works and I'm not yet convinced that better way exist.
But I definitively like that we find the best way to cope
with security.

About Athorization. We must introduce a standard HTTP way of
entering username/password as soon as possible. The other
way (AIDA way) is an automatic redirection to logon page if
you hit a page without permission. After logon, you are
redirected back to origin page.

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?

About database. OmniBase is more and more interesting choice
for me and quite well supported by Dolphin folks. And Jerry
is planing to port AIDA and also connect it to OmniBase. I
will talk with David Gorisek, if he is willing to help here.

I'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>

Regards

Thanks for the follow-up.. I appreciate your insights.
 

----
Ken Treis
[hidden email]

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.