[hunchentoot-devel] Re: hunchentoot authorization

[Bryan Emrys]

Agreed. I got too mono-focused there. 

Bryan

On Saturday 12 April 2008 03:25:33 pm Cyrus Harmon wrote:
> 
> 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
> >
> 
>