It just occurred to me how sweet it would be to be able to query a hypothetical sessions database and write views for it just like any other data in the database. Imagine having an admin CouchDB app (like Futon, or maybe part of Futon) that can dynamically show you numbers of active user sessions over time, histograms of session durations, etc.
On Fri, Feb 20, 2009 at 10:41 PM, Stefan Karpinski < stefan.karpin...@gmail.com> wrote: > Ok, good to know. I could go did around the development code, but it might > be much more expedient just to ask. Is there a special users database? What > about sessions? It would be cool if those were just databases with special > metadata (only settable by admin users, of course). What's in a user_ctx > object at the moment? Does it correspond to an actual CouchDB record? > > > On Fri, Feb 20, 2009 at 3:56 PM, Chris Anderson <jch...@apache.org> wrote: > >> On Fri, Feb 20, 2009 at 3:48 PM, Stefan Karpinski >> <stefan.karpin...@gmail.com> wrote: >> > Thoughts (just brainstorming here): >> > >> > I think it makes sense to separate authentication and permissions. >> > Pure authentication is just about verifying that the user is who they >> > claim to be. Permissions are about deciding which users are allowed to >> > see or do what. Cleanly separating is good: ideally you should be able >> > to completely swap out your authentication mechanism, switching from, >> > say basic auth to SSL + digest auth, and keep the application logic >> > about who gets access to what completely unchanged. For example, >> > Apache accomplishes this by doing whatever authentication it's doing >> > and then passing the REMOTE_USER environment variable >> > (http://httpd.apache.org/docs/1.3/misc/FAQ-F.html#remote-user-var) >> > with the authenticated user name. Whatever CGI or variant thereof >> > (FCGI, etc.) then just does whatever it sees fit to do with that user >> > name. >> > >> > Also, authentication is typically slow: even hashing a user/pass combo >> > takes some CPU — this is not something that you want to have done on >> > every request. That's why the notion of user sessions exists (at least >> > from the security perspective; there are other notions of session). >> > That argues for having the CouchDB server process manage >> > authentication and letting the application developer define custom >> > functions for deciding whether (user,resource) pairs are acceptable or >> > not. I.e. the CouchDB process somehow validates that the request is >> > coming from someone who has provided adequate proof that they are who >> > they claim to be, via HTTP basic/digest auth or whatever. Then the >> > application can just decide whether the pre-authenticated user is >> > allowed to access a particular resource. >> > >> >> This is pretty much how it works now. CouchDB manages sending the >> user_ctx object into the validation function. The user_ctx object then >> lets the function know if the user is an admin or in any other groups. >> Then the validation function may accept or reject the update >> accordingly. >> >> There is a related issue about how to let the client application know >> which user they are validated as, so that they can correctly fill out >> author fields etc. >> >> > More thoughts coming... >> > >> > On Fri, Feb 20, 2009 at 3:16 PM, Stefan Karpinski >> > <stefan.karpin...@gmail.com> wrote: >> >>> I wish I could say we've got such a clear picture of it. >> >> >> >> Good to get in on the planning stages! >> >> >> >>> The easiest way to cleave the knot is probably to rely on 3rd party >> >>> auth like OpenID or OAuth (I don't quite know which parts of which >> >>> we're interested in). >> >> >> >> OpenID is great, but I don't think it's viable to force people to use >> it. >> >> >> >>> Identifying users as URLs would make things easier on application >> devs, I think. >> >>> >> >>> If every app will need to implement something like this, it makes >> >>> sense to me to have the CouchDB host manage the session, even if apps >> >>> can keep their own user-preferences docs if they wish. Being logged >> >>> into all the apps on a node seems a lot more intuitive than having to >> >>> create accounts for each one. If the user is identified with a URL, >> >>> then preferences etc can be replicated to other hosts while everything >> >>> "just works". >> >> >> >> I think that nailing this problem would go a *long* way towards making >> >> CouchDB popular not only for it's nice distributed properties and >> >> such, but also because would make writing modern web apps drastically >> >> easier. Because literally *every* non-trivial web application needs to >> >> do user authentication. Having it _just work_ without having to worry >> >> about it is a massive win. Moreover, if the database was actually >> >> aware of application-level authentication and could enforce it, then >> >> it would increase the security of CouchDB-based web apps. Errors in >> >> business logic would be much less likely to accidentally expose data. >> >> How easy is it to forget in Rails that you need to filter the objects >> >> in some table by the user_id field? >> >> >> >> On Fri, Feb 20, 2009 at 3:01 PM, Chris Anderson <jch...@apache.org> >> wrote: >> >>> >> >>> On Fri, Feb 20, 2009 at 1:51 PM, Stefan Karpinski >> >>> <stefan.karpin...@gmail.com> wrote: >> >>> > I'm not entirely clear what level of user auth is being addressed >> here. >> >>> > >> >>> > On the one hand, there's the system-level sense of a user that >> traditional >> >>> > databases have: i.e. something equivalent to a UNIX user account, >> but in the >> >>> > database, which has to be created by an admin and can then be >> granted >> >>> > table-level access and various administrative rights (create user, >> create >> >>> > database, create table). >> >>> > >> >>> > On the other hand, there's the application-level sense of user: i.e. >> a >> >>> > record in a users table, which is given access or not given access >> to >> >>> > database records via the web application stack at a higher level, >> which sits >> >>> > between the database and the client's web browser (or whatever). >> >>> > >> >>> > The current CouchDB notion of admin user seems to fall into the >> former >> >>> > category, while what most applications need falls into the latter >> category. >> >>> > One irritation of all application-level authentication schemes I've >> ever >> >>> > encountered is that the database does not give you any support for >> >>> > application-level user auth. If CouchApps are really going to be >> feasible, >> >>> > CouchDB (clearly) needs to solve the application-level user >> authentication >> >>> > problem. >> >>> > >> >>> > My sense is that the goal is to somehow merge the two senses of >> database >> >>> > user, and thereby cleave the Gordian knot in two. Is that sense >> correct? >> >>> >> >>> I wish I could say we've got such a clear picture of it. >> >>> >> >>> The easiest way to cleave the knot is probably to rely on 3rd party >> >>> auth like OpenID or OAuth (I don't quite know which parts of which >> >>> we're interested in). >> >>> >> >>> Identifying users as URLs would make things easier on application >> devs, I think. >> >>> >> >>> If every app will need to implement something like this, it makes >> >>> sense to me to have the CouchDB host manage the session, even if apps >> >>> can keep their own user-preferences docs if they wish. Being logged >> >>> into all the apps on a node seems a lot more intuitive than having to >> >>> create accounts for each one. If the user is identified with a URL, >> >>> then preferences etc can be replicated to other hosts while everything >> >>> "just works". >> >>> >> >>> Thanks for the feedback! >> >>> >> >>> -- >> >>> Chris Anderson >> >>> http://jchris.mfdz.com >> >> >> > >> >> >> >> -- >> Chris Anderson >> http://jchris.mfdz.com >> > >
