docids starting with underscore

[Brian Candler <B....@pobox.com>]

I'm not sure if this is a bug, or simply a case of "don't do that"!

{"couchdb":"Welcome","version":"0.9.0a739811-incubating"}

I see it is possible to create documents with IDs starting with an
underscore, such as _view, using the _bulk_docs API

$ curl -X POST -d '{"docs":[{"_id":"_view","foo":"bar"}]}'
http://localhost:5984/test_suite_db/_bulk_docs; echo
{"ok":true,"new_revs":[{"id":"_view","rev":"3737122827"}]}

[Aside: use of "id" and "_id" doesn't appear to be consistent, but that's a
separate discussion]

If you then try to retrieve this document using the normal GET API, it barfs
a 405 error (not surprisingly, since dbname/_view has a special meaning)

However it is still possible to retrieve it using multi document fetch:

$ curl 'http://localhost:5984/test_suite_db/_all_docs?key="_view"&include_docs=true'
{"total_rows":10,"offset":3,"rows":[
{"id":"_view","key":"_view","value":{"rev":"3737122827"},
"doc":{"_id":"_view","_rev":"3737122827","foo":"bar"}}
]}

I wonder if there is any value in the server restricting the docid?

However even if it did, it's still up to application writers to be careful
of this, especially if one document refers to another. E.g. if a malicious
client writes

   "customer_id":"_external/foo/bar"

into an invoice record, then it may make another client perform requests
with unforeseen side effects when looking up the 'customer' for this
invoice.

So at least, perhaps the client-side API libraries ought to forbid docids
which begin with underscore, even if the underlying database doesn't.

Anyway, just a thought. (I came across this issue when modifying a Rails app
to use /things/name instead of /things/id - which is easily done using
to_param. I then had an ambiguity as to whether /things/new was an
individual thing, or an action on the collection of things!)

Regards,

Brian.

Re: docids starting with underscore

[Chris Anderson <jc...@apache.org>]

On Wed, Feb 4, 2009 at 3:33 AM, Jan Lehnardt <ja...@apache.org> wrote:
>> I wonder if there is any value in the server restricting the docid?
>
> Doc ids with an underscore are private to CouchDB. This is documented
> behaviour. So "Don't do that" :) Maybe it is feasible to check for leading
> underscores everywhere.
>

Yes I think it's a bug that it allows you to create docs with id's
that start with _ but not _design or _local. We should add a test and
then fix the bug.

I've created a ticket on jira and put it in the 0.9 queue

https://issues.apache.org/jira/browse/COUCHDB-238



-- 
Chris Anderson
http://jchris.mfdz.com

Re: docids starting with underscore

[Jan Lehnardt <ja...@apache.org>]

On 3 Feb 2009, at 22:24, Brian Candler wrote:

> I'm not sure if this is a bug, or simply a case of "don't do that"!
>
> {"couchdb":"Welcome","version":"0.9.0a739811-incubating"}
>
> I see it is possible to create documents with IDs starting with an
> underscore, such as _view, using the _bulk_docs API
>
> $ curl -X POST -d '{"docs":[{"_id":"_view","foo":"bar"}]}'
> http://localhost:5984/test_suite_db/_bulk_docs; echo
> {"ok":true,"new_revs":[{"id":"_view","rev":"3737122827"}]}
>
> [Aside: use of "id" and "_id" doesn't appear to be consistent, but  
> that's a
> separate discussion]

It is consistent. the field name is always `id` unless it is in a JSON
document, where it is `_id`.


> If you then try to retrieve this document using the normal GET API,  
> it barfs
> a 405 error (not surprisingly, since dbname/_view has a special  
> meaning)
>
> However it is still possible to retrieve it using multi document  
> fetch:
>
>
> $ curl 'http://localhost:5984/test_suite_db/_all_docs? 
> key="_view"&include_docs=true'
> {"total_rows":10,"offset":3,"rows":[
> {"id":"_view","key":"_view","value":{"rev":"3737122827"},
> "doc":{"_id":"_view","_rev":"3737122827","foo":"bar"}}
> ]}

This works because the matching of _view happens in the HTTP layer of
CouchDB. The `_all_docs` multi-key matching happens in the view server.


> I wonder if there is any value in the server restricting the docid?

Doc ids with an underscore are private to CouchDB. This is documented
behaviour. So "Don't do that" :) Maybe it is feasible to check for  
leading
underscores everywhere.

Cheers
Jan
--