[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864698#action_12864698 ] Daniel Truemper commented on COUCHDB-720: - Hi, I just experienced the same behaviour but have some more background information. I have an nginx reverse proxy for the ssl stuff. On both DBs there are users and admins. From the client DB I am now trying to do the following in Futon: - start replication from https://$user:pas...@$server:5984/$db to http://localhost:5984/$db (on the local machine I am already logged in and on both DBs I am admin). When I try to replicate using pull replication, all documents are replicated except the design document. At the time the replicator tries to GET the design document a HTTP 401 is being sent from the server DB. When I do the same using push replication the design document is being replicated. I am unsure if this is intentional but if so I could use a little help ;). Best Daniel Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864730#action_12864730 ] Filipe Manana commented on COUCHDB-720: --- Daniel, if you: - specify source as https://$user:pas...@$server:5984/$db - and target as http://$user:pas...@$localhost:5984/$db does it work? Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: rewrite security
On Thu, May 6, 2010 at 12:35 AM, J Chris Anderson jch...@gmail.com wrote: Devs, Today I wrote a patch and backported to 0.11.x, concerning the security guarantees made by the rewriter. Previously we'd allowed the rewriter to include as many .. segments in the target path as the developer wanted. This is great for flexibility, and allows you to create a vhost which doesn't provide the full couchdb api but also can access more than one database. I've changed the default behavior so that you can only have a maximum of 2 .. segments in your rewrite paths, so eg you can rewrite from /db/_design/foo/_rewrite to /db/ or /db/somedoc or /db/_design/foo/_show/bar but you CAN'T rewrite to /otherdb/anything This allows databases to be jailed inside vhosts, which is very important for security as we move forward. Prior to this patch, there was no way to run untrusted apps on the same CouchDB VM as each other. Now, using vhosts and by putting apps/dbs on different domains, we can protect the applications from each other. My patch maintains the previous functionality (unlimited rewriting), but it is configured to be off by default. By default secure_rewrites=true. So if you are currently relying on cross-db rewrites, you'll need to edit your local.ini file to set secure_rewrites=false There are some missing parts in my implementation. I plan to finish this change by making a configurable whitelist of global_httpd handlers that *can* be accessed within vhosts. The ones I can think of are: _utils _uuids _session _oauth _users And some installations might want to turn on others (_replicate, _stats, etc), hence the list should be configurable. My plan is to implement this as a whitelist that is checked by the vhost engine, so that these global handlers are available on all vhosts. This way you can easily add a database that needs to be available to all your vhosts using a single configuration directive. I think this plan is sane, but please let me know if you see issues that I'm missing. Chris Well vhost don't stop someone to access to the whole db currently if so remove the Host info or such. But I'm not sure this path worth it since we can limit security per database for readers such. In fact, I would do in the other way, ie secure the resource that need to be secured: _replicate, _all_dbs, _users, ... . And maybe secure by default all resource to admin or a default group of user. Using this way would allow other users of couchdb (those who aren't using couchapps) to have a way to secure these accesses to between untrusted users. In your case, for hosting multiple non trusted couchapps, you would just have to set default permissions to a couchdb node and it would do the trick too. What do you think about it ? - benoit
[jira] Updated: (COUCHDB-741) incompete error message when creating database with invalid name
[
https://issues.apache.org/jira/browse/COUCHDB-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank updated COUCHDB-741:
--
Attachment: COUCHDB-741.patch
trivial fix of error message
incompete error message when creating database with invalid name
Key: COUCHDB-741
URL: https://issues.apache.org/jira/browse/COUCHDB-741
Project: CouchDB
Issue Type: Bug
Components: Database Core, Documentation
Affects Versions: 0.11
Reporter: Andrew Alexander
Priority: Trivial
Attachments: COUCHDB-741.patch
The illegal_database_name reason fails to specify all the requirements,
causing it to be misleading. See example below. (failed to begin with a
letter)
x...@dev:$ restclient http://127.0.0.1:5984/4df57220060c10afb9aad04dec097388
{
error: illegal_database_name,
reason: Only lowercase characters (a-z), digits (0-9), and any of the
characters _, $, (, ), +, -, and / are allowed
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
_changes timeout has a max of 60 seconds?
I'm trying to use _changes with feed=continuous and a timeout greater than the default - however, couch always uses the default of 60 seconds. Timeouts smaller than the default work as expected. It seems get_changes_timeout/2 in couch_changes.erl is responsible for this by selecting the smallest of the specified and default timeout. While is sounds reasonable to have a default of 60 seconds, there doesn't seem to be an obvious case for also making that the max - *some* maximum might be reasonable, but 60 seconds seems pretty low. Should I open a bug, or is this really the intent? If the latter, I'll update the wiki accordingly... Thanks, Mark
