On Sun, Jan 17, 2010 at 8:15 PM, Chris Anderson <[email protected]> wrote:
> I've also normalized some naming, like user docs to name/password
> instead of "username" in some places.
Nice!
> The /_session response now returns something like:
>
> {
> userCtx : {
> name : "[email protected]",
> roles : ["_admin", "_replicator", "author"]
> },
> info : {
> authentication_db : "_users",
> authenticated : ["cookie"],
> authentication_handlers : ["oauth", "cookie", "http_basic"]
> },
> }
>
> I flirted with the idea of including the userDoc but I'll leave that
> up to someone else to tackle.
Including the userDoc is only really useful if convention is going to
allow devs to add whatever fields they'd like to user docs as far as I
can tell...
> TODO:
>
> * bcrypt (I think there are some JS implementations out there)
> * security object (I think this will be a local doc that apps can
> populate with the help of an admin.)
+1 for the security object, as we discussed on IRC the other day. I'd
be happy to see something as simple as the following:
Validation functions would take a new argument, 'security'. If in the
database that the validation function is running for there exists a
document with id '_security', that document would be passed as that
new argument. The document could have whatever structure a dev felt
was appropriate, as long as it has the correct id. If there was no
document, an empty object (or null?) would be passed.
What is the plan for 'read' permissions, if any? I need to be able to
grant users read permission on one database but not another...
I appreciate the great work so far Chris!
Dave
