I would argue that this sort of plumbing sits between the server and the application. It's the kind of infrastructure that multiple application uses and it probably needs to know something about the server in order to function properly. But the whole distinction between application and server is rather nebulous and arbitrary.
What I have in mind is a relative simple, extensible system for managing users/passwords/groups and for allowing one to server pages with various scenarios in mind, such as requiring that a user become an authenticated user before seeing certain pages, that different users see different content based on various properties, etc... Clearly more complex applications may have more demanding requirements for this functionality, but a basic, extensible infrastructure sitting on top of hunchentoot seems like it would enable folks to have a leg up when beginning to write the kind of apps you mention.
Cyrus
On Apr 12, 2008, at 3:16 PM, Bryan Emrys wrote:
Is this a server function or an app function? By the time you start rolling out full ACL capability, aren't you pretty far removed from the server?
On the app I'm maintaining (non-lisp), data can come in from several sources with different licenses. Some of the data sources give us site-wide licenses, others are limited to certain specific individuals. So it isn't just a question of is the user authorized to see a certain area of the site (and, if so, do they have read/add/ edit capabilities within that area), but data searches need to see if this chunk of data has license restrictions which further limit the read/add/edit capability for that specific piece of data.
So a typical internal user will say - log me in and the app knows that this user is limited to area 123. The user asks "tell me everything we know about in XYZ in Thailand" The app then looks for everything in the system about XYZ in Thailand which this user is allowed to view and builds a page from that data.
Since "pages" are built on the fly from the database search results, there is no such thing as an "authorized page". A different user who may be on more or fewer or just different data source licenses would see a completely "different" page. (Different in the sense that the data on the page would be different - the url would be exactly the same.) The user could even see a page with no data, just a generic error message that either we have no data on the particular question or they are not authorized for access to whatever data we have on the particular question. Since the webapp only knows that the database search returned no data, it has no idea whether there is no data in the system or just no data accessible by this user's permissions.
If a user has access to multiple areas within the webapp, they can choose the generic home page or an area specific home page, but even those pages are built on the fly. E.g., someone might have worldwide access, but their concentration is on Europe, so their default homepage after logging in shows only recent data updates for Europe.
Then again, I may be missing the whole point here.
Bryan