[hunchentoot-devel] Re: hunchentoot authorization

[Cyrus Harmon]

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
>