couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: Per Document Filtering/Authorization
Date Mon, 29 Nov 2010 18:29:16 GMT
I was thinking the _access field would hold either a validation function or
(more often) a path to a function on a design document. And for that matter,
I'm not sure what (if anything) we gain by having the function definition
itself on the document, just a field to point to the correct place in the
design document should be sufficient. This way entire classes of documents
could share the same validation function.

I don't think you can modify the document during validate_doc_update, but it
seems pretty easy to require the _access field to be a certain value to
accept creating the document by the user. This would be analogous to the
type/class of the document and could be well known without any decrease in
security.

I was thinking that putting the "flag" that turns on document security at
the document level would eliminate the need to run the validation function
for documents that don't require security, so performance should only really
decrease for secured systems (except for a hopefully cheap check to see if
the flag exists at all).

Another reason to put this on the document is that it simplifies the
validation function for lots of different document types in the same
database.

I think the view access validation function in design document is a very
good addition to the security model as well ... possibly this could be a
optional method defined as part of the view definition itself.



On Mon, Nov 29, 2010 at 11:14 AM, Bram Neijt <bneijt@gmail.com> wrote:

> Yes, we could add something like _access to control access to the
> document, however that would mean that the validate_doc_update
> function will have to add this to the documents (you can't wait for
> the user to add the validation function).
>
> That makes it seem simpler to add an access function at the database
> level, where you would still be able to do something like
> "if(document.type == 'should_secure') { //heavy security for the
> document }" with the added bonus of not having to replicate your
> security code in all your documents.
>
> Maybe we would be better of with a system that allows us to match
> requests with user information, because we need something to protect
> the view from unauthorized access as well? If somebody thinks that
> would be a good idea, feel free to add a comment.
>
> Please comment on the "per document access function" vs "per database
> access function".
>
> Greets,
>
> Bram
>
> On Mon, Nov 29, 2010 at 3:20 PM, Fedor Indutny <fedor.indutny@gmail.com>
> wrote:
> > Yep, that's what I was talking about!
> >
> > 2010/11/29 Chad George <chad@mgproducts.com>
> >
> >> Bram Neijt has recently indicated interest in working on per document
> >> authorization. I've mentioned an idea a few times here and on the user
> list
> >> but never got any real response so I'm still not sure what the general
> >> consensus about the idea is.
> >>
> >> My idea is to add a new special field on the document that indicates a
> >> function that can modify the document before returning it to the user.
> >> function(doc, req) {
> >>  /* modify doc based on req or just throw exception */
> >>  return doc;
> >> }
> >>
> >> I think the main place that document authorization is needed is limiting
> >> (or
> >> sanitizing) access to raw documents. Especially in a mixed authorized
> >> and anonymous access environment.
> >>
> >> Shows/Lists/Updates are already pretty easy to enforce a security
> barrier
> >> within a single database, but direct access to documents makes certain
> >> applications difficult (or impossible) to secure without a middle server
> >> layer.
> >>
> >> With a filter function attached to the document, we would have minimal
> >> overhead for when doc auth wasn't required so only secured documents
> would
> >> get any real performance penalty. By allowing the filter function to
> return
> >> a modified document --or-- throw an exception we could get access denial
> >> and
> >> minor sanitizing with the same mechanism.
> >>
> >> This would work nicely with include-docs for views that need security.
> And
> >> it doesn't seem that hard to keep secure info out of being embedded in
> >> views
> >> and view reductions in the first place. I recently saw a suggestion on
> the
> >> mailing list to have an access control function for views on the design
> >> document, that seems like a nice fix for securing access to views
> >> themselves.
> >>
> >> - Chad
> >>
> >
> >
> >
> > --
> > Cheers,
> > Fedor Indutny.
> >
> > Skype: fedor.indutny
> > Gtalk: fedor.indutny@gmail.com
> > Github: http://github.com/donnerjack13589
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message