[jira] Commented: (COUCHDB-759) rewriter should be securely jailed in a single database by default
[
https://issues.apache.org/jira/browse/COUCHDB-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985296#action_12985296
]
Martin Hilbig commented on COUCHDB-759:
---
hi,
i would like to see this bug reopend, since the rewriter jail can be easily
broken
when there is a rewrite rule with an *. consider this one:
{
from: /doc/*,
to: /../../*,
method: GET
}
this rewrite rule provides cross-db access like these (even behind a vhost):
http://vhost.localhost:5984/doc/../../../../../otherdb/docid
http://vhost.localhost:5984/doc/../../../../../_all_dbs
so i propose that either rewrite rules with an asterix in them should be
considered insecure (and therefore catched by secure_rewrites option) or
(even better) couchdb should forbid requests with to many .. in them.
have fun
rewriter should be securely jailed in a single database by default
--
Key: COUCHDB-759
URL: https://issues.apache.org/jira/browse/COUCHDB-759
Project: CouchDB
Issue Type: Bug
Reporter: Chris Anderson
This will allow us to isolate databases using vhosts and the browser's
single-origin policy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COUCHDB-759) rewriter should be securely jailed in a single database by default
[ https://issues.apache.org/jira/browse/COUCHDB-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt reopened COUCHDB-759: -- Reopening because of last comment. rewriter should be securely jailed in a single database by default -- Key: COUCHDB-759 URL: https://issues.apache.org/jira/browse/COUCHDB-759 Project: CouchDB Issue Type: Bug Reporter: Chris Anderson This will allow us to isolate databases using vhosts and the browser's single-origin policy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Idea: Piggyback doc on conflict
+1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
Re: code style
On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com wrote: Imo the thing we could have in view, except this plugin support, is a simple api to call any part of couchdb we need. Something as simple as the HTTP api but for erlang. I'm thinking to have a couchbeam pure erlang api for example just for that. It would also help us to make new HTTP layer using webmachine for example or anything. fabric an hovercraft are also good inspiration. I'm pretty ready to do such thing. Does it worth a thread to discuss about it? You already have that with the new replicator. It brings a module named couch_api_wrap.erl. For now, it only has functions necessary for the replicator to operate both with local and remote databases. Nevertheless, it already covers a significant subset of the CouchDB API - benoît -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: Idea: Piggyback doc on conflict
Oooh, crosspost. Had a similar chat on IRC last night. I'm -0 on returning the doc during a 409 PUT just because I think there are other options that might be preferred. For example, allowing a read_repair function in ddocs, that would take all conflicting revisions as input and return the resolved document as output. Or allowing a resolve_conflict function that is called at the moment of conflict creation, allowing it to be downgraded to a non-conflicting update. With either, or both, of those mechanisms, the proposed one here is unnecessary. B. On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne dio...@dionne-associates.com wrote: +1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
Re: Idea: Piggyback doc on conflict
These are also interesting ideas, but I don't think they adequately satisfy this particular write-heavy scenario. The client receiving the 409 has in hand the doc they wished to write and may just to add a field or update one. A general resolve_conflict function is a good idea for certain collaborative environments but I don't think would handle this specific case. Having the conflict causing update return the doc that caused it seems really ideal. I'm still +1 on it On Jan 23, 2011, at 7:51 AM, Robert Newson wrote: Oooh, crosspost. Had a similar chat on IRC last night. I'm -0 on returning the doc during a 409 PUT just because I think there are other options that might be preferred. For example, allowing a read_repair function in ddocs, that would take all conflicting revisions as input and return the resolved document as output. Or allowing a resolve_conflict function that is called at the moment of conflict creation, allowing it to be downgraded to a non-conflicting update. With either, or both, of those mechanisms, the proposed one here is unnecessary. B. On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne dio...@dionne-associates.com wrote: +1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
Re: Idea: Piggyback doc on conflict
The confusion point here is that there are two different types of conflict. 1. _rev mismatch on regular write. — This is the quoted scenario. Returning the expected _rev with the error result allows to remove an extra GET request. The replicator never does this. 2. _rev mismatch on replication write (or a client with the all_or_nothing option). The response is always 201, even when a conflict is created, the caller isn't being notified (or maybe it is, but the replicator isn't using this). read-repair function assume that conflicts appear as in 2. Returning the expected _rev in a failed write only happens in 1. Cheers Jan -- On 23 Jan 2011, at 14:23, Robert Dionne wrote: These are also interesting ideas, but I don't think they adequately satisfy this particular write-heavy scenario. The client receiving the 409 has in hand the doc they wished to write and may just to add a field or update one. A general resolve_conflict function is a good idea for certain collaborative environments but I don't think would handle this specific case. Having the conflict causing update return the doc that caused it seems really ideal. I'm still +1 on it On Jan 23, 2011, at 7:51 AM, Robert Newson wrote: Oooh, crosspost. Had a similar chat on IRC last night. I'm -0 on returning the doc during a 409 PUT just because I think there are other options that might be preferred. For example, allowing a read_repair function in ddocs, that would take all conflicting revisions as input and return the resolved document as output. Or allowing a resolve_conflict function that is called at the moment of conflict creation, allowing it to be downgraded to a non-conflicting update. With either, or both, of those mechanisms, the proposed one here is unnecessary. B. On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne dio...@dionne-associates.com wrote: +1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
Re: Idea: Piggyback doc on conflict
I can see utility in the original proposal, my only point is whether it would still be utile if other mechanisms were introduced. You've clarified that the two cases are distinct, so it seems reasonable to me now. However, I'd hope we'd return the doc and not just the _rev. The only thing returning the rev itself will do is encourage blind overwrites. B. On Sun, Jan 23, 2011 at 2:58 PM, Jan Lehnardt j...@apache.org wrote: The confusion point here is that there are two different types of conflict. 1. _rev mismatch on regular write. — This is the quoted scenario. Returning the expected _rev with the error result allows to remove an extra GET request. The replicator never does this. 2. _rev mismatch on replication write (or a client with the all_or_nothing option). The response is always 201, even when a conflict is created, the caller isn't being notified (or maybe it is, but the replicator isn't using this). read-repair function assume that conflicts appear as in 2. Returning the expected _rev in a failed write only happens in 1. Cheers Jan -- On 23 Jan 2011, at 14:23, Robert Dionne wrote: These are also interesting ideas, but I don't think they adequately satisfy this particular write-heavy scenario. The client receiving the 409 has in hand the doc they wished to write and may just to add a field or update one. A general resolve_conflict function is a good idea for certain collaborative environments but I don't think would handle this specific case. Having the conflict causing update return the doc that caused it seems really ideal. I'm still +1 on it On Jan 23, 2011, at 7:51 AM, Robert Newson wrote: Oooh, crosspost. Had a similar chat on IRC last night. I'm -0 on returning the doc during a 409 PUT just because I think there are other options that might be preferred. For example, allowing a read_repair function in ddocs, that would take all conflicting revisions as input and return the resolved document as output. Or allowing a resolve_conflict function that is called at the moment of conflict creation, allowing it to be downgraded to a non-conflicting update. With either, or both, of those mechanisms, the proposed one here is unnecessary. B. On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne dio...@dionne-associates.com wrote: +1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
Re: Idea: Piggyback doc on conflict
On 23 Jan 2011, at 16:03, Robert Newson wrote: I can see utility in the original proposal, my only point is whether it would still be utile if other mechanisms were introduced. You've clarified that the two cases are distinct, so it seems reasonable to me now. However, I'd hope we'd return the doc and not just the _rev. The only thing returning the rev itself will do is encourage blind overwrites. You are correct of course. In my attempt to clarify one issue, I confuddled another. Sorry :) Cheers Jan -- B. On Sun, Jan 23, 2011 at 2:58 PM, Jan Lehnardt j...@apache.org wrote: The confusion point here is that there are two different types of conflict. 1. _rev mismatch on regular write. — This is the quoted scenario. Returning the expected _rev with the error result allows to remove an extra GET request. The replicator never does this. 2. _rev mismatch on replication write (or a client with the all_or_nothing option). The response is always 201, even when a conflict is created, the caller isn't being notified (or maybe it is, but the replicator isn't using this). read-repair function assume that conflicts appear as in 2. Returning the expected _rev in a failed write only happens in 1. Cheers Jan -- On 23 Jan 2011, at 14:23, Robert Dionne wrote: These are also interesting ideas, but I don't think they adequately satisfy this particular write-heavy scenario. The client receiving the 409 has in hand the doc they wished to write and may just to add a field or update one. A general resolve_conflict function is a good idea for certain collaborative environments but I don't think would handle this specific case. Having the conflict causing update return the doc that caused it seems really ideal. I'm still +1 on it On Jan 23, 2011, at 7:51 AM, Robert Newson wrote: Oooh, crosspost. Had a similar chat on IRC last night. I'm -0 on returning the doc during a 409 PUT just because I think there are other options that might be preferred. For example, allowing a read_repair function in ddocs, that would take all conflicting revisions as input and return the resolved document as output. Or allowing a resolve_conflict function that is called at the moment of conflict creation, allowing it to be downgraded to a non-conflicting update. With either, or both, of those mechanisms, the proposed one here is unnecessary. B. On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne dio...@dionne-associates.com wrote: +1 this sounds like an excellent idea. On Jan 23, 2011, at 12:21 AM, kowsik wrote: I've been spending a fair bit of time on profiling the performance aspects of Couch. One common recurring theme is updating documents on a write-heavy site. This is currently what happens: PUT /db/doc_id - 409 indicating conflict loop do GET /db/doc_id - 200 PUT /db/doc_id - 201 (successful and returns the new _rev) end until we get a 201 What would be beneficial is if I can request the current doc during PUT like so: PUT /db/doc_id?include_doc=true - 409 conflict (but the 'doc' at the current _rev is returned) This would allow the caller to simply take the doc that was returned, update it and try PUT again (eliminate the extra GET). This is especially valuable when the app is on one geo and the db is in yet another (think couchone or cloudant). 2 cents, K. --- http://twitter.com/pcapr http://labs.mudynamics.com
