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

To me, this seems like pushing Hunchentoot more in the direction of being a web framework than just a webserver. Not that there's anything wrong with that, of course, but it could probably be just as easily done with a library that sits on top and implements a light-weight framework. Rob

On 13 apr 2008, at 03:21, Cyrus Harmon wrote:

This certainly doesn't have to be part of hunchentoot.

Perhaps this can be resolved by considering Hunchentoot a web-server and, like Robert said, not a web application framework; if this deals with HTTP details (like HTTP layer authentication and authorization) the answer is simply 'yes'. If your authorization and authentication is not at the HTTP layer, I would say it is part of your application and not HTPP and thus should remain there.

Although a covers-everything web framework has allure at first; I've often experienced disappointment after actually using some due to un- layered or incomplete design forcing you to do it their way or having to use horrible workarounds and hacks that make you feel dirty.

However, there is definitely a place for frameworks that sit on top of a generic web-server with a good HTTP layer API. I hope Hunchentoot will remain being such a web-server.

In fact, I firmly believe there is even place for a layer in-between (think Python's WSGI but perhaps richer) so that web frameworks can be written in a web-server agnostic way and can perhaps even cooperate and nest each-other.

Woops, sorry for hijacking your thread with that - I'll get off my soapbox now ;)

-Arjan

On Apr 12, 2008, at 5:45 PM, Robert Synnott wrote:

...

To me, this seems like pushing Hunchentoot more in the direction of being a web framework than just a webserver. Not that there's anything wrong with that, of course, but it could probably be just as easily done with a library that sits on top and implements a light-weight framework.

On Apr 13, 2008, at 3:49 AM, Michael Weber wrote:

I actually find it overly flexible. (This is perhaps another of the "organic growth" areas.) There are several ways to plug into the dispatcher. At the moment, I am using this:

Yes, I think this is part of the challenge here. There are many ways to plug the sort of functionality I'm thinking of into hunchentoot. I'm not satisfied with the current approach taken by hunchentoot-auth and the myriad of choices for plugging this stuff in is what initially precipitated this discussion.

At the risk of taking this discussion from the philosophical to the practical, allow me to discuss some options for wedging in the authorization stuff.

+ authorized-page macro

The existing approach is an authorized-page -style macro that wraps each page and does the following:

* check if an https connection is required and if so that we're actually using an https connection otherwise, redirect to an https page on the appropriate port. * either check that the supplied user and password are correct or that the user's session was properly authenticated. If necessary, squirrel away the user name in a per-session hash-table and set a flag that in a per-session hash-table that the user is authenticated.

The disadvantage of this approach is that it requires wrapping the code that generates each page with the authorized-page macro. One can't take arbitrary request handling code and make the page require authorization without somehow wrapping it, or another function that calls it, with this macro.

+ *meta-dispatcher*

One could rig up *meta-dispatcher* such that it checked for authorization and possibly redirect things along the way. The problem with this is that there is only one meta-dispatcher, so you only get to do this once per hunchentoot instance.

And, of course, one could override the value of *dispatch-table*, which is what the default *meta-dispatcher* returns.

+ server-dispatch-table

Similarly to the case of *meta-dispatcher*, one could use the dispatch- table slot of the server instance to hijack the dispatch and check for authentication. But it's not clear to me how the elements of this table should be ordered.

Interestingly, there's a dispatch-request generic function that could be used with a suitably defined class.

Clearly there's plenty of rope for extensibility here, the challenge, for hunchentoot-auth at least, is figuring which of these hooks to exploit.

(defvar *toplevel-routing-table* (let ((rt (make-instance 'ht-routing-table))) (shiftf (get-routes rt) hunchentoot:*dispatch-table* rt) rt))

(defmethod hunchentoot:dispatch-request ((table routing-table)) (let ((controller (find-controller table *request*))) (handle-request controller *request*)))

However, another option for me would be to just push

(lambda () (hunchentoot:dispatch-request *toplevel-routing-table* *request*))

onto hunchentoot:*dispatch-table*. And I haven't even look at the meta-dispatcher stuff and starting multiple server instances.

Right. Multiple server-instances is another issue and it becomes important for what i'm doing because I use two server instances, one for http and one for https. There's no built-in infrastructure for managing multiple "servers". One could imagine some sort of meta- server (or renaming the server class to a listener and allowing for the server to have multiple listeners, but I guess that's just a nomenclature issue).

There's probably a way to simplify all this without losing any power or convenience.

Right.

Cheers, Michael BTW: The reasons behind all this:

• I like the mappings between URLs and handlers a little more

descriptive than bare function designators, for example, to print out the mapping or appropriate Apache config stanzas. So I use CLOS objects. Alternatively, I could have used (:metaclass funcallable- standard-class).

I agree. I like having more of the "metadata" kept with the function too.

• I like to be able to rearrange URL mappings while running in

development. (make-prefix-matcher "/foo/") is a little too static for my taste.

• I bundle several end points (handlers) together (into a

"controller"), because on their own, they don't make sense. Also, the end points don't know anything about the URL they are mapped to.

• I can deploy a single controller several times on different URL

routes (e.g., "/~foo/...", "/~bar/...", etc.). The routing dissects the URL and provides parameters to controller and end points. Deploying multiple "web apps" comes for free.

• Authentication is done by Apache, for the moment, because it's

convenient and works for files served statically, too.

Hmm... I've taken the perhaps crazy approach of using ht for everything, static files, CGI scripts, etc...

• Authorization is done by Apache and by controllers (for, say, DB

access), because all end points are usually subject to the same rules. End points can do additional checks with finer granularity.

Thanks for your comments,

Cyrus