[jira] [Created] (COUCHDB-1833) Couchdb not starting on erlang R16B01
Dawid Jańczak created COUCHDB-1833:
--
Summary: Couchdb not starting on erlang R16B01
Key: COUCHDB-1833
URL: https://issues.apache.org/jira/browse/COUCHDB-1833
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Dawid Jańczak
CouchDB version: 1.2.2
Erlang version: R16B01
system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
x86_64 GNU/Linux
Hi!
My package manager decided to upgrade Erlang yesterday and CouchDB won't start
after reboot. Here is the message I get when running /usr/bin/couchdb manually:
{"init terminating in
do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1830) IO timeout not configurable
[ https://issues.apache.org/jira/browse/COUCHDB-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690137#comment-13690137 ] Stefan Kögl commented on COUCHDB-1830: -- I was not able to reliably reproduce those errors so far. They happen from time to time on (virtualized) productive systems, always when under relatively high load. Is there something else that I can provide for debugging? > IO timeout not configurable > --- > > Key: COUCHDB-1830 > URL: https://issues.apache.org/jira/browse/COUCHDB-1830 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.3 >Reporter: Stefan Kögl >Priority: Minor > Labels: timeout > > I occasionally encounter the timeout shown in the log at > https://gist.github.com/stefankoegl/5772860. > According to [~janl] in #couchdb this is a generic gen_Server timeout (5s) > and currently not configurable. As this might not be enough in some > circumstances, there should probably be a setting for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1833) Couchdb not starting on erlang R16B01
[
https://issues.apache.org/jira/browse/COUCHDB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690139#comment-13690139
]
Robert Newson commented on COUCHDB-1833:
This is a known issue, CouchDB is not compatible with the R16 series yet.
> Couchdb not starting on erlang R16B01
> -
>
> Key: COUCHDB-1833
> URL: https://issues.apache.org/jira/browse/COUCHDB-1833
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Dawid Jańczak
>
> CouchDB version: 1.2.2
> Erlang version: R16B01
> system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
> x86_64 GNU/Linux
> Hi!
> My package manager decided to upgrade Erlang yesterday and CouchDB won't
> start after reboot. Here is the message I get when running /usr/bin/couchdb
> manually:
> {"init terminating in
> do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1833) Couchdb not starting on erlang R16B01
[
https://issues.apache.org/jira/browse/COUCHDB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690149#comment-13690149
]
Dave Cottlehuber commented on COUCHDB-1833:
---
I think we will need to add asn as a dependency for crypto too in future, seems
a few people are having problems with that on erlang-q.
> Couchdb not starting on erlang R16B01
> -
>
> Key: COUCHDB-1833
> URL: https://issues.apache.org/jira/browse/COUCHDB-1833
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Dawid Jańczak
>
> CouchDB version: 1.2.2
> Erlang version: R16B01
> system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
> x86_64 GNU/Linux
> Hi!
> My package manager decided to upgrade Erlang yesterday and CouchDB won't
> start after reboot. Here is the message I get when running /usr/bin/couchdb
> manually:
> {"init terminating in
> do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1833) Couchdb not starting on erlang R16B01
[
https://issues.apache.org/jira/browse/COUCHDB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690152#comment-13690152
]
Robert Newson commented on COUCHDB-1833:
hm, we should only need to depend on "crypto", but ok. With that solved, it
still won't work because of the parameterized module stuff, right?
> Couchdb not starting on erlang R16B01
> -
>
> Key: COUCHDB-1833
> URL: https://issues.apache.org/jira/browse/COUCHDB-1833
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Dawid Jańczak
>
> CouchDB version: 1.2.2
> Erlang version: R16B01
> system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
> x86_64 GNU/Linux
> Hi!
> My package manager decided to upgrade Erlang yesterday and CouchDB won't
> start after reboot. Here is the message I get when running /usr/bin/couchdb
> manually:
> {"init terminating in
> do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
couchdb pull request: Add a configurable whitelist of public user propertie...
GitHub user rnewson opened a pull request: https://github.com/apache/couchdb/pull/68 Add a configurable whitelist of public user properties By default no user properties are public and attempts to view a users document other than your own will return a 404. If the public_fields setting of the users_db config section is set to a list of field names, however, you will see that subset of fields for any user. You can merge this pull request into a Git repository by running: $ git pull https://github.com/rnewson/couchdb user-doc-filtering Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/68.patch
couchdb pull request: couch_users_db: introduce public_users option
Github user indutny closed the pull request at: https://github.com/apache/couchdb/pull/67
couchdb pull request: couch_users_db: introduce public_users option
GitHub user indutny reopened a pull request: https://github.com/apache/couchdb/pull/67 couch_users_db: introduce public_users option When `couchdb.public_users` is set to `true`, getting `/_users/id` will return user document with sensitive information stripped. You can merge this pull request into a Git repository by running: $ git pull https://github.com/indutny/couchdb feature/public_users Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/67.patch
Re: Fauxton Tidings
Do like the new UI! :) Thanks for the update Russell & team! A few notes and answers inline. On Jun 19, 2013, at 20:16 , Russell Branca wrote: > (Also gisted at https://gist.github.com/chewbranca/5816534) > > # Fauxton Tidings > > It's been some time since we've had a Fauxton update. There's been a > number of exciting updates with active tasks, replication, UI updates > and more. So let's dive in. > > ## Active Tasks > > Active tasks is an interesting item. Traditionally in Futon, active > tasks have been relegated to the status page, but I'm of the opinion > Fauxton should not only provide an interactive interface to your data, > but also a visual overview of the current pulse of your CouchDB > server. Things like active tasks, stats, and logs should be displayed > prominently in some sort of dashboard page. Garren has been working on > the logs and stats views in Fauxton, and DCH and Banjiewen have been > experimenting with new stats collectors. Long term I would love to > have a front dashboard showing you live views into this data. > > To start with, we're making active tasks a first class citizen of the > application. Any time you're in Fauxton, it will poll \_active\_tasks > and give you an immediate overview of the number of replications, > compactions, and indexing jobs currently running, giving you immediate > feedback on what is going on behind the scenes. Sue has been working > on an initial active tasks page that lists all the current tasks with > progress bars and ability to filter on the different types of tasks. I very much like the idea of a dashboard. Note that currently /_active_tasks requires admin creds, so there is an interesting user interface problem that needs solving if the first page one gets to requires that. I think this could be easily done by requiring a log-in for Futon proper, and changing CouchDB‘s setup procedure that the user/admin has to set a CouchDB Server Admin on first-start, something that makes sense for various other reasons as well. But there might be other solutions to this and I don’t want to prescribe anything here, I just wanted to point out that there is an interesting issue we need to consider :) > Long term I want to extend the active tasks page to do more advanced > visualizations and calculate rate of change to give estimates of time > to completion. What else would be useful here? How do you want to see > an overview of the background tasks running? I think we should formulate a few questions that the dashboard should answer by default. Something like: - how is my CouchDB doing? - if it isn’t doing well, what an I do? etc. > ## Replication > > In addition to active tasks, Sue has been working on a replication > interface. Step one is to build the transient replicator interface, > basically the same interface that is in Futon now, but with a proper > interface for all the different options such as choosing a filter > function, and specifying doc ids. > > Step two is build out a proper interface around the _replicator > database, allowing you to create new persistent replications, > introspect existing replications, look at historic replications, and > also to visually expose the powerful advanced options of the new > replicator allowing higher throughput replications. > > What kinds of interfaces sounds useful for interacting with the > replicator database? What would you find useful for creating and > managing replications through Fauxton? While a bit oblique in implementation, I like the git “remote” concept and I think it makes sense in the CouchDB context. Whether a remote is another CouchDB installation and databases are “branches” (in git lingo) or whether a database is a remote is up to decision, but I’d like to be able to configure a set of remotes for my current server (manually and automatically) and then start/stop/schedule/observe replication between the local couch and a “remote”, or two “remotes”, or whatever else makes sense. > One question I have, are transient replications through _replicate > deprecated in favor of interacting with the _replicator database? > at least as the default? Given that you can do one time replications > through the _replicator database, should we default to creating a doc > in _replicator rather than just POSTing to _replicate? We could always > have an option for both, but given that it will store stats and allow > you to see past history, it seems useful to use the _replicator db as > the default option. Thoughts? These interfaces really need to be consolidated, and maybe the “remotes” idea above gives us a way out. > ## UI Updates > > I'm excited to report that there are some great new designs for the > Fauxton UI. > > ### _all_dbs page > >  > > Notice in the left hand bar the "active
Re: Fauxton Tidings
On Fri, Jun 21, 2013 at 1:58 PM, Jan Lehnardt wrote: > I think this could be easily done by requiring a log-in for Futon proper, > and changing CouchDB‘s setup procedure that the user/admin has to set > a CouchDB Server Admin on first-start, something that makes sense for > various other reasons as well. I'd really like to keep Admin Party mode around (including no-login Futon usage). Cheers, Dirkjan
Re: Fauxton Tidings
On Jun 21, 2013, at 7:58 AM, Jan Lehnardt wrote: >> Step two is build out a proper interface around the _replicator >> database, allowing you to create new persistent replications, >> introspect existing replications, look at historic replications, and >> also to visually expose the powerful advanced options of the new >> replicator allowing higher throughput replications. >> >> What kinds of interfaces sounds useful for interacting with the >> replicator database? What would you find useful for creating and >> managing replications through Fauxton? > > While a bit oblique in implementation, I like the git “remote” concept > and I think it makes sense in the CouchDB context. Whether a remote > is another CouchDB installation and databases are “branches” (in git lingo) > or whether a database is a remote is up to decision, but I’d like > to be able to configure a set of remotes for my current server (manually > and automatically) and then start/stop/schedule/observe replication > between the local couch and a “remote”, or two “remotes”, or whatever > else makes sense. Co-opting the git parlance could work well. For my money the right analogy is that a CouchDB server is a remote and databases take the place of repos. Branching happens at the granularity of a document, not a database, and replication pushes all branches of all documents in the database to the remote. Adam
[jira] [Created] (COUCHDB-1834) FAUXTON: Update Bootstrap, Lodash & jQuery to current versions
Sue Lockwood created COUCHDB-1834: - Summary: FAUXTON: Update Bootstrap, Lodash & jQuery to current versions Key: COUCHDB-1834 URL: https://issues.apache.org/jira/browse/COUCHDB-1834 Project: CouchDB Issue Type: Task Components: Fauxton Reporter: Sue Lockwood Bootstrap is 2.2 atm, update to 2.3.2 jQuery needs to be updated to 1.10.1 Lodash needs to be updated to 1.3.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1833) Couchdb not starting on erlang R16B01
[
https://issues.apache.org/jira/browse/COUCHDB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690254#comment-13690254
]
Dave Cottlehuber commented on COUCHDB-1833:
---
I tracked it down, *ssl* depends on asn1 via public_key. As we're not doing OTP
releases, this needs to be managed in couch_app.erl. I'll put this into master,
and the various COUCHDB-1696 branches I have.
diff --git i/src/couchdb/couch_app.erl w/src/couchdb/couch_app.erl
index 24b2f3a..9644877 100644
--- i/src/couchdb/couch_app.erl
+++ w/src/couchdb/couch_app.erl
@@ -20,7 +20,7 @@
start(_Type, DefaultIniFiles) ->
IniFiles = get_ini_files(DefaultIniFiles),
-case start_apps([crypto, public_key, sasl, inets, oauth, ssl, ibrowse,
syntax_tools, compiler, xmerl, mochiweb, os_mon]) of
+case start_apps([crypto, asn1, public_key, sasl, inets, oauth, ssl,
ibrowse, syntax_tools, compiler, xmerl, mochiweb, os_mon]) of
ok ->
couch_server_sup:start_link(IniFiles);
{error, Reason} ->
> Couchdb not starting on erlang R16B01
> -
>
> Key: COUCHDB-1833
> URL: https://issues.apache.org/jira/browse/COUCHDB-1833
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Dawid Jańczak
>
> CouchDB version: 1.2.2
> Erlang version: R16B01
> system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
> x86_64 GNU/Linux
> Hi!
> My package manager decided to upgrade Erlang yesterday and CouchDB won't
> start after reboot. Here is the message I get when running /usr/bin/couchdb
> manually:
> {"init terminating in
> do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1653) ./bootstrap failed with automake 1.13
[ https://issues.apache.org/jira/browse/COUCHDB-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-1653. --- Resolution: Fixed Fix Version/s: 1.4 Fixed in [e62fa49|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e62fa49621e7f4725afafa2e1ba4d3ae68cd1dbb] > ./bootstrap failed with automake 1.13 > - > > Key: COUCHDB-1653 > URL: https://issues.apache.org/jira/browse/COUCHDB-1653 > Project: CouchDB > Issue Type: Bug >Reporter: Benoit Chesneau > Fix For: 1.4 > > > configure.ac:22: error: 'AM_CONFIG_HEADER': this macro is obsolete. > You should use the 'AC_CONFIG_HEADERS' macro instead. > /usr/local/Cellar/automake/1.13.1/share/aclocal-1.13/obsolete-err.m4:14: > AM_CONFIG_HEADER is expanded from... > configure.ac:22: the top level > autom4te: /usr/bin/m4 failed with exit status: 1 > aclocal: error: echo failed with exit status: 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1784) enable distcheck for VPATH builds
[ https://issues.apache.org/jira/browse/COUCHDB-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber closed COUCHDB-1784. - Resolution: Fixed Assignee: Dave Cottlehuber Seeing as we released 1.3.1 using this patch I'll assume it worked. > enable distcheck for VPATH builds > - > > Key: COUCHDB-1784 > URL: https://issues.apache.org/jira/browse/COUCHDB-1784 > Project: CouchDB > Issue Type: Improvement > Components: Build System >Reporter: Dave Cottlehuber >Assignee: Dave Cottlehuber >Priority: Minor > Fix For: 1.3.1 > > Attachments: 0001-vpath-and-license.skip.patch > > > VPATH doesn't work for distcheck due to license.skip being an absolute path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
On Jun 21, 2013, at 14:16 , Adam Kocoloski wrote: > On Jun 21, 2013, at 7:58 AM, Jan Lehnardt wrote: > >>> Step two is build out a proper interface around the _replicator >>> database, allowing you to create new persistent replications, >>> introspect existing replications, look at historic replications, and >>> also to visually expose the powerful advanced options of the new >>> replicator allowing higher throughput replications. >>> >>> What kinds of interfaces sounds useful for interacting with the >>> replicator database? What would you find useful for creating and >>> managing replications through Fauxton? >> >> While a bit oblique in implementation, I like the git “remote” concept >> and I think it makes sense in the CouchDB context. Whether a remote >> is another CouchDB installation and databases are “branches” (in git lingo) >> or whether a database is a remote is up to decision, but I’d like >> to be able to configure a set of remotes for my current server (manually >> and automatically) and then start/stop/schedule/observe replication >> between the local couch and a “remote”, or two “remotes”, or whatever >> else makes sense. > > Co-opting the git parlance could work well. For my money the right analogy > is that a CouchDB server is a remote and databases take the place of repos. > Branching happens at the granularity of a document, not a database, and > replication pushes all branches of all documents in the database to the > remote. I didn’t make this very clear, maybe I have a simplified concept of git remotes in my head. I don’t think git server / repos are a useful analogy, because most people start out at the repo level and then down. Remotes are just locations for a repo (you know this). What I did not have in mind is a semantic analogy as you describe (which is totally valid!), I was coming from my usage of git remote: git remote add remote-name url git fetch remote-name After which remote-name/branches are available to me. My correlation of databases and branches is purely on the ”what is on the top level of a remote”. A CouchDB remote could be another CouchDB server and a fictional `couch remote add remote-name url` would make `remote-name` available for further operations, e.g. `couch replicate db-name remote/db-name` (read git push note that git lists the remote first in reality, but I want to express a from-to relationship so I can also say: `couch replicate remote/db-name db-name` to pull changes from the remote db). `couch list remote-name` would give me list of databases available on the target server etc. Alternatively a CouchDB remote could be the location of a database anywhere identified with an URL. (the concept of remotes as proxies for branches took a while for me to grok when learning git, so maybe we can simplify this in the context of CouchDB: couch remote add remote-db-name url couch replicate local-db-name remote-db-name Or the reverse: couch replicate remote-db-name local-db-name Listing databases on another server would be out of band for this model. But maybe that is confusing and your approach is better because it also has a semantic mapping of operations further down, but I hope this shows where my thinking came from. All I really wanted here is see if we could make things simpler for our users and that there is some work to be done :) Best Jan --
[jira] [Commented] (COUCHDB-1833) Couchdb not starting on erlang R16B01
[
https://issues.apache.org/jira/browse/COUCHDB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690282#comment-13690282
]
ASF subversion and git services commented on COUCHDB-1833:
--
Commit 136b28991fa40b92cde6e544f49c8fd18b9340ab in branch refs/heads/master
from [~dch]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=136b289 ]
support R16B01
Due to non-OTP-ness, couch need to start its own OTP apps. R16B01
requires asn1 as a dependency for public_key.
Closes COUCHDB-1833.
> Couchdb not starting on erlang R16B01
> -
>
> Key: COUCHDB-1833
> URL: https://issues.apache.org/jira/browse/COUCHDB-1833
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Dawid Jańczak
>
> CouchDB version: 1.2.2
> Erlang version: R16B01
> system: Linux work 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013
> x86_64 GNU/Linux
> Hi!
> My package manager decided to upgrade Erlang yesterday and CouchDB won't
> start after reboot. Here is the message I get when running /usr/bin/couchdb
> manually:
> {"init terminating in
> do_boot",{{badmatch,{error,{{app_would_not_start,ssl},{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]],[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1829) Fauxton User Experience Redesign
[ https://issues.apache.org/jira/browse/COUCHDB-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sue Lockwood updated COUCHDB-1829: -- Attachment: N_FfvrQzUmdvIZ4uC-r3S9w1qMSj5Xd7pDVFxxg46-0.png tgHqUAghVhA76zZTcLGyFocYq1npgplMeUuoxM-ysWQ.png lfF6vhEXlEivV9QELkNr8EP9bkYAXmQPKLhrWCsHi4Q.png Here are the design comps > Fauxton User Experience Redesign > > > Key: COUCHDB-1829 > URL: https://issues.apache.org/jira/browse/COUCHDB-1829 > Project: CouchDB > Issue Type: Task > Components: Fauxton >Reporter: Sue Lockwood > Attachments: lfF6vhEXlEivV9QELkNr8EP9bkYAXmQPKLhrWCsHi4Q.png, > N_FfvrQzUmdvIZ4uC-r3S9w1qMSj5Xd7pDVFxxg46-0.png, > tgHqUAghVhA76zZTcLGyFocYq1npgplMeUuoxM-ysWQ.png > > > Fauxton is getting a UI redesign so it's less like a twitter bootstrap > website and more like an application. > Changes include new templates, css changes and adjustments to make the > current liquid layout more useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1835) Navbar layout refactor
Sue Lockwood created COUCHDB-1835: - Summary: Navbar layout refactor Key: COUCHDB-1835 URL: https://issues.apache.org/jira/browse/COUCHDB-1835 Project: CouchDB Issue Type: Bug Components: Fauxton Reporter: Sue Lockwood Navbar renders itself multiple times and needs a refactor. Should either be refactored to insert a view for each nav item, with event binding on the collection of navitems to add more, or some of the render() calls need to be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1836) Grunt task icon font compiler
Sue Lockwood created COUCHDB-1836: - Summary: Grunt task icon font compiler Key: COUCHDB-1836 URL: https://issues.apache.org/jira/browse/COUCHDB-1836 Project: CouchDB Issue Type: Sub-task Components: Fauxton Reporter: Sue Lockwood We are using a custom icon font in this redesign and there needs to be an easy way for devs to add new icons to the font. Currently it's set up using fontcustom http://fontcustom.com/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
On Jun 21, 2013, at 15:35 , Jan Lehnardt wrote: > > On Jun 21, 2013, at 14:16 , Adam Kocoloski wrote: > >> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt wrote: >> Step two is build out a proper interface around the _replicator database, allowing you to create new persistent replications, introspect existing replications, look at historic replications, and also to visually expose the powerful advanced options of the new replicator allowing higher throughput replications. What kinds of interfaces sounds useful for interacting with the replicator database? What would you find useful for creating and managing replications through Fauxton? >>> >>> While a bit oblique in implementation, I like the git “remote” concept >>> and I think it makes sense in the CouchDB context. Whether a remote >>> is another CouchDB installation and databases are “branches” (in git lingo) >>> or whether a database is a remote is up to decision, but I’d like >>> to be able to configure a set of remotes for my current server (manually >>> and automatically) and then start/stop/schedule/observe replication >>> between the local couch and a “remote”, or two “remotes”, or whatever >>> else makes sense. >> >> Co-opting the git parlance could work well. For my money the right analogy >> is that a CouchDB server is a remote and databases take the place of repos. >> Branching happens at the granularity of a document, not a database, and >> replication pushes all branches of all documents in the database to the >> remote. > > I didn’t make this very clear, maybe I have a simplified concept of git > remotes in my head. I don’t think git server / repos are a useful analogy, sorry, this may sound a bit rude, what I mean is “I don’t understand yet how it would be a useful analogy, give me some time to think about it” :) > because most people start out at the repo level and then down. Remotes are > just locations for a repo (you know this). > > What I did not have in mind is a semantic analogy as you describe (which is > totally valid!), I was coming from my usage of git remote: > > git remote add remote-name url > git fetch remote-name > > After which remote-name/branches are available to me. My correlation of > databases and branches is purely on the ”what is on the top level of a > remote”. > > A CouchDB remote could be another CouchDB server and a fictional `couch > remote add remote-name url` would make `remote-name` available for further > operations, e.g. `couch replicate db-name remote/db-name` (read git push > note that git lists the remote first in > reality, but I want to express a from-to relationship so I can also say: > `couch replicate remote/db-name db-name` to pull changes from the remote db). > `couch list remote-name` would give me list of databases available on the > target server etc. > > Alternatively a CouchDB remote could be the location of a database anywhere > identified with an URL. (the concept of remotes as proxies for branches took > a while for me to grok when learning git, so maybe we can simplify this in > the context of CouchDB: > > couch remote add remote-db-name url > couch replicate local-db-name remote-db-name > > Or the reverse: > > couch replicate remote-db-name local-db-name > > Listing databases on another server would be out of band for this model. > > > But maybe that is confusing and your approach is better because it also has a > semantic mapping of operations further down, but I hope this shows where my > thinking came from. > > All I really wanted here is see if we could make things simpler for our users > and that there is some work to be done :) > > Best > Jan > -- > > > > > > >
Re: Fauxton Tidings
On Jun 21, 2013, at 15:35 , Jan Lehnardt wrote: > > On Jun 21, 2013, at 14:16 , Adam Kocoloski wrote: > >> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt wrote: >> Step two is build out a proper interface around the _replicator database, allowing you to create new persistent replications, introspect existing replications, look at historic replications, and also to visually expose the powerful advanced options of the new replicator allowing higher throughput replications. What kinds of interfaces sounds useful for interacting with the replicator database? What would you find useful for creating and managing replications through Fauxton? >>> >>> While a bit oblique in implementation, I like the git “remote” concept >>> and I think it makes sense in the CouchDB context. Whether a remote >>> is another CouchDB installation and databases are “branches” (in git lingo) >>> or whether a database is a remote is up to decision, but I’d like >>> to be able to configure a set of remotes for my current server (manually >>> and automatically) and then start/stop/schedule/observe replication >>> between the local couch and a “remote”, or two “remotes”, or whatever >>> else makes sense. >> >> Co-opting the git parlance could work well. For my money the right analogy >> is that a CouchDB server is a remote and databases take the place of repos. >> Branching happens at the granularity of a document, not a database, and >> replication pushes all branches of all documents in the database to the >> remote. > > I didn’t make this very clear, maybe I have a simplified concept of git > remotes in my head. I don’t think git server / repos are a useful analogy, sorry, this may sound a bit rude, what I mean is “I don’t understand yet how it would be a useful analogy, give me some time to think about it” :) > because most people start out at the repo level and then down. Remotes are > just locations for a repo (you know this). > > What I did not have in mind is a semantic analogy as you describe (which is > totally valid!), I was coming from my usage of git remote: > > git remote add remote-name url > git fetch remote-name > > After which remote-name/branches are available to me. My correlation of > databases and branches is purely on the ”what is on the top level of a > remote”. > > A CouchDB remote could be another CouchDB server and a fictional `couch > remote add remote-name url` would make `remote-name` available for further > operations, e.g. `couch replicate db-name remote/db-name` (read git push > note that git lists the remote first in > reality, but I want to express a from-to relationship so I can also say: > `couch replicate remote/db-name db-name` to pull changes from the remote db). > `couch list remote-name` would give me list of databases available on the > target server etc. > > Alternatively a CouchDB remote could be the location of a database anywhere > identified with an URL. (the concept of remotes as proxies for branches took > a while for me to grok when learning git, so maybe we can simplify this in > the context of CouchDB: > > couch remote add remote-db-name url > couch replicate local-db-name remote-db-name > > Or the reverse: > > couch replicate remote-db-name local-db-name > > Listing databases on another server would be out of band for this model. > > > But maybe that is confusing and your approach is better because it also has a > semantic mapping of operations further down, but I hope this shows where my > thinking came from. > > All I really wanted here is see if we could make things simpler for our users > and that there is some work to be done :) > > Best > Jan > -- > > > > > > >
Re: Fauxton Tidings
On Jun 21, 2013, at 10:07 AM, Jan Lehnardt wrote: > > On Jun 21, 2013, at 15:35 , Jan Lehnardt wrote: > >> >> On Jun 21, 2013, at 14:16 , Adam Kocoloski wrote: >> >>> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt wrote: >>> > Step two is build out a proper interface around the _replicator > database, allowing you to create new persistent replications, > introspect existing replications, look at historic replications, and > also to visually expose the powerful advanced options of the new > replicator allowing higher throughput replications. > > What kinds of interfaces sounds useful for interacting with the > replicator database? What would you find useful for creating and > managing replications through Fauxton? While a bit oblique in implementation, I like the git “remote” concept and I think it makes sense in the CouchDB context. Whether a remote is another CouchDB installation and databases are “branches” (in git lingo) or whether a database is a remote is up to decision, but I’d like to be able to configure a set of remotes for my current server (manually and automatically) and then start/stop/schedule/observe replication between the local couch and a “remote”, or two “remotes”, or whatever else makes sense. >>> >>> Co-opting the git parlance could work well. For my money the right analogy >>> is that a CouchDB server is a remote and databases take the place of repos. >>> Branching happens at the granularity of a document, not a database, and >>> replication pushes all branches of all documents in the database to the >>> remote. >> >> I didn’t make this very clear, maybe I have a simplified concept of git >> remotes in my head. I don’t think git server / repos are a useful analogy, > > sorry, this may sound a bit rude, what I mean is “I don’t understand yet how > it would be a useful analogy, give me some time to think about it” :) No offense taken :) There's definitely value in making this sort of analogy with developers; let's keep at it and I'm sure we'll converge on a standard way of expressing it. Adam
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690388#comment-13690388 ] Nathan Vander Wilt commented on COUCHDB-1824: - Hmm, I'm assuming Jens you mean more the necessary revision tree tracking than the actual HTTP calls? > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690407#comment-13690407 ] Jens Alfke commented on COUCHDB-1824: - They're both needed for interoperability. The HTTP calls used by the replicator are documented now, but only on the unofficial wiki, and only because I added documentation along the way while I wrote the TouchDB replicator. At the time a lot of the info existed only in the source code and in the heads of people like Filipe and Damien. My unstated assumption here is that replication interoperability is a good thing, and that other database implementations should support the same protocol and algorithms so they can freely replicate with CouchDB and each other. That's very powerful, and I don't know of any other open protocols for replication. > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
couchdb pull request: Add a configurable whitelist of public user propertie...
Github user rnewson closed the pull request at: https://github.com/apache/couchdb/pull/68
[jira] [Created] (COUCHDB-1837) Incorrect HTTP response on attempt to update other user doc with public fields enabled
Alexander Shorin created COUCHDB-1837:
-
Summary: Incorrect HTTP response on attempt to update other user
doc with public fields enabled
Key: COUCHDB-1837
URL: https://issues.apache.org/jira/browse/COUCHDB-1837
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Alexander Shorin
When `public_fields` are specified (see
[8d7ab8b1|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60]
commit) and regular user tries to update other user doc, CouchDB return HTTP
404 Not Found request while HTTP 403 Forbidden is more expected.
Steps to reproduce:
1. Enable `public_fields`
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'"name,email,whatever"' -H "Content-Type: application/json" --user couch_admin
{code}
2. Setup some users
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{"name":"abc", "roles":[], "type":"user", "password": "cba"}' -H
"Content-Type: application/json"
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{"name":"def", "roles":[], "type":"user", "password": "fed"}' -H
"Content-Type: application/json"
{code}
3. Now user `abc` may browse `def` doc
{code}
> curl -v http://abc:cba@localhost:5984/_users/org.couchdb.user:def
>
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: text/plain; charset=utf-8
Date: Fri, 21 Jun 2013 22:48:03 GMT
ETag: "1-fa20c151bb6946527d261e9ef4338923"
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
{"_id":"org.couchdb.user:def","_rev":"1-fa20c151bb6946527d261e9ef4338923","name":"def"}
{code}
4. Try to save `def`'s doc:
{code}
curl -v -X PUT http://abc:cba@localhost:5984/_users/org.couchdb.user:def -d
'{}' -H "Content-Type: application/json"
HTTP/1.1 404 Object Not Found
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 22:49:44 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 41
Cache-Control: must-revalidate
{"error":"not_found","reason":"missing"}
{code}
Since `org.couchdb.user:def` doc is actually exists and available for direct
GET request 404 response is incorrect and confuses while HTTP 403 Forbidden is
expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1837) Incorrect HTTP response on attempt to update other user doc with public fields enabled
[
https://issues.apache.org/jira/browse/COUCHDB-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690862#comment-13690862
]
Robert Newson commented on COUCHDB-1837:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization
will not help and the request SHOULD NOT be repeated. If the request method was
not HEAD and the server wishes to make public why the request has not been
fulfilled, it SHOULD describe the reason for the refusal in the entity. If the
server does not wish to make this information available to the client, the
status code 404 (Not Found) can be used instead.
> Incorrect HTTP response on attempt to update other user doc with public
> fields enabled
> --
>
> Key: COUCHDB-1837
> URL: https://issues.apache.org/jira/browse/COUCHDB-1837
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Alexander Shorin
>
> When `public_fields` are specified (see
> [8d7ab8b1|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60]
> commit) and regular user tries to update other user doc, CouchDB return HTTP
> 404 Not Found request while HTTP 403 Forbidden is more expected.
> Steps to reproduce:
> 1. Enable `public_fields`
> {code}
> curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
> '"name,email,whatever"' -H "Content-Type: application/json" --user
> couch_admin
> {code}
> 2. Setup some users
> {code}
> curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
> '{"name":"abc", "roles":[], "type":"user", "password": "cba"}' -H
> "Content-Type: application/json"
> curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
> '{"name":"def", "roles":[], "type":"user", "password": "fed"}' -H
> "Content-Type: application/json"
> {code}
> 3. Now user `abc` may browse `def` doc
> {code}
> > curl -v http://abc:cba@localhost:5984/_users/org.couchdb.user:def
> >
> HTTP/1.1 200 OK
> Cache-Control: must-revalidate
> Content-Length: 88
> Content-Type: text/plain; charset=utf-8
> Date: Fri, 21 Jun 2013 22:48:03 GMT
> ETag: "1-fa20c151bb6946527d261e9ef4338923"
> Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
> {"_id":"org.couchdb.user:def","_rev":"1-fa20c151bb6946527d261e9ef4338923","name":"def"}
> {code}
> 4. Try to save `def`'s doc:
> {code}
> curl -v -X PUT http://abc:cba@localhost:5984/_users/org.couchdb.user:def -d
> '{}' -H "Content-Type: application/json"
> HTTP/1.1 404 Object Not Found
> Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
> Date: Fri, 21 Jun 2013 22:49:44 GMT
> Content-Type: text/plain; charset=utf-8
> Content-Length: 41
> Cache-Control: must-revalidate
> {"error":"not_found","reason":"missing"}
> {code}
> Since `org.couchdb.user:def` doc is actually exists and available for direct
> GET request 404 response is incorrect and confuses while HTTP 403 Forbidden
> is expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1837) Incorrect HTTP response on attempt to update other user doc with public fields enabled
[
https://issues.apache.org/jira/browse/COUCHDB-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690869#comment-13690869
]
Alexander Shorin commented on COUCHDB-1837:
---
Actually, server had already made this information (user's doc) available to
the client (with response on GET request against the resource). Server has
nothing to share in the response of PUT one, except the decision had he
accepted or rejected posted data from the client against available (for the
client) resource.
> Incorrect HTTP response on attempt to update other user doc with public
> fields enabled
> --
>
> Key: COUCHDB-1837
> URL: https://issues.apache.org/jira/browse/COUCHDB-1837
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Alexander Shorin
>
> When `public_fields` are specified (see
> [8d7ab8b1|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60]
> commit) and regular user tries to update other user doc, CouchDB return HTTP
> 404 Not Found request while HTTP 403 Forbidden is more expected.
> Steps to reproduce:
> 1. Enable `public_fields`
> {code}
> curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
> '"name,email,whatever"' -H "Content-Type: application/json" --user
> couch_admin
> {code}
> 2. Setup some users
> {code}
> curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
> '{"name":"abc", "roles":[], "type":"user", "password": "cba"}' -H
> "Content-Type: application/json"
> curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
> '{"name":"def", "roles":[], "type":"user", "password": "fed"}' -H
> "Content-Type: application/json"
> {code}
> 3. Now user `abc` may browse `def` doc
> {code}
> > curl -v http://abc:cba@localhost:5984/_users/org.couchdb.user:def
> >
> HTTP/1.1 200 OK
> Cache-Control: must-revalidate
> Content-Length: 88
> Content-Type: text/plain; charset=utf-8
> Date: Fri, 21 Jun 2013 22:48:03 GMT
> ETag: "1-fa20c151bb6946527d261e9ef4338923"
> Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
> {"_id":"org.couchdb.user:def","_rev":"1-fa20c151bb6946527d261e9ef4338923","name":"def"}
> {code}
> 4. Try to save `def`'s doc:
> {code}
> curl -v -X PUT http://abc:cba@localhost:5984/_users/org.couchdb.user:def -d
> '{}' -H "Content-Type: application/json"
> HTTP/1.1 404 Object Not Found
> Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
> Date: Fri, 21 Jun 2013 22:49:44 GMT
> Content-Type: text/plain; charset=utf-8
> Content-Length: 41
> Cache-Control: must-revalidate
> {"error":"not_found","reason":"missing"}
> {code}
> Since `org.couchdb.user:def` doc is actually exists and available for direct
> GET request 404 response is incorrect and confuses while HTTP 403 Forbidden
> is expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: State of Debian Packaging
On Thu, 2013-06-20 at 10:53 -0700, Randall Leeds wrote: > I saw that my packaging efforts came up in the IRC meeting yesterday > and I wasn't there to report. > > Here's what's done: > - Split the packaging into couchdb and couchdb-bin as Ubuntu did downstream Will check why it makes sense. > You can try it by installing git-buildpackage, cloning the pkg-couchdb > repository, using git-dch to create a new debian/changelog entry for > 1.3.1, and running git-buildpackage. Please note that previously I couldn't build couchdb 1.3.0 . The Erlang version in the Debian archives is (was?) too new for it. Hope it's solved with 1.3.1 then. Even if I was forcing it to build, Futon was failing due to some incompatibility between Erlang versions. Is it still supported? > Here's what remaining to be done, based on my notes from previous > conversations with Laszlo and others: > - Use system libyajl-dev > - Use system libspeedy-dev > - Use system libjs-json > - Use system libjs-coffeescript > - Publish to dist.apache.org > > The first 4 are Debian policy issues. Sure, it should be a policy for everyone. Meaning don't do code duplication but use the ones from the system. If one has a security fix, then it's fixed for all dependent applications. But if someone embeds them and those don't get the security fix, you will remain affected. Sometimes blindly, as you may not realize that the application contains other libraries. > Laszlo: If you already have a repo for this work anywhere that you > would prefer I use I would be glad to collaborate there. Not yet, but we can discuss it in private. On Thu, 2013-06-20 at 14:33 -0700, Randall Leeds wrote: > In the case of the Debian packaging, I'd like to not have it in the > main source tree, since that creates pain if downstream packagers > decide to diverge from our way of doing it. It's not a problem for me. The 'new' source package format (3.0 ie quilt) works this around. Easily as it gets the upstream tarball, unpacks it and deletes debian/ from the tree and applies my debian/ subdir. Thus I don't even see if upstream has debian/ or not. Laszlo/GCS
[jira] [Created] (COUCHDB-1838) Specifying public_fields parameter discloses all user docs
Alexander Shorin created COUCHDB-1838:
-
Summary: Specifying public_fields parameter discloses all user docs
Key: COUCHDB-1838
URL: https://issues.apache.org/jira/browse/COUCHDB-1838
Project: CouchDB
Issue Type: Bug
Reporter: Alexander Shorin
When public_fields are specified it's possible to retrieve all available user
docs, no matter does they contains specified public fields or not.
0. Setup some users:
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{"name":"abc", "roles":[], "type":"user", "password": "cba"}' -H
"Content-Type: application/json"
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{"name":"def", "roles":[], "type":"user", "password": "fed"}' -H
"Content-Type: application/json"
{code}
1. Check the old behavior without public_fields:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 403 Forbidden
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 23:12:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 87
Cache-Control: must-revalidate
{"error":"forbidden","reason":"Only admins can access _all_docs of system
databases."}
{code}
2. Specify some public fields that no one actually has:
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'"no_user_will_never_has_ziz_field_in_his_doc"' -H "Content-Type:
application/json" --user couch_admin
{code}
3. Try step 1 one more time:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: "55N0CA8VM2Z0DQO85L1PM20XS"
Date: Fri, 21 Jun 2013 23:15:05 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{"total_rows":6,"offset":0,"rows":[
{"id":"_design/_auth","key":"_design/_auth","value":{"rev":"1-619db7ba8551c0de3f3a178775509611"}},
{"id":"org.couchdb.user:abc","key":"org.couchdb.user:abc","value":{"rev":"1-64d299987b4df59c048171a8ab8ba951"}},
{"id":"org.couchdb.user:def","key":"org.couchdb.user:def","value":{"rev":"1-479a3e8a66652838706cc49544730a34"}},
{"id":"org.couchdb.user:foo","key":"org.couchdb.user:foo","value":{"rev":"1-3859ee3742314dcb4b4f1ffaba398c91"}},
{"id":"org.couchdb.user:mia","key":"org.couchdb.user:mia","value":{"rev":"1-f87f5003323e705d8c7a533cdd0a267c"}},
{"id":"org.couchdb.user:root","key":"org.couchdb.user:root","value":{"rev":"1-f43dadbe5e780f392a6bd283686b3704"}}
]}
{code}
Same for anonymous user:
{code}
curl -v http://localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: "55N0CA8VM2Z0DQO85L1PM20XS"
Date: Sat, 22 Jun 2013 00:04:17 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{"total_rows":6,"offset":0,"rows":[
{"id":"_design/_auth","key":"_design/_auth","value":{"rev":"1-619db7ba8551c0de3f3a178775509611"}},
{"id":"org.couchdb.user:abc","key":"org.couchdb.user:abc","value":{"rev":"1-64d299987b4df59c048171a8ab8ba951"}},
{"id":"org.couchdb.user:def","key":"org.couchdb.user:def","value":{"rev":"1-479a3e8a66652838706cc49544730a34"}},
{"id":"org.couchdb.user:foo","key":"org.couchdb.user:foo","value":{"rev":"1-3859ee3742314dcb4b4f1ffaba398c91"}},
{"id":"org.couchdb.user:mia","key":"org.couchdb.user:mia","value":{"rev":"1-f87f5003323e705d8c7a533cdd0a267c"}},
{"id":"org.couchdb.user:root","key":"org.couchdb.user:root","value":{"rev":"1-f43dadbe5e780f392a6bd283686b3704"}}
]}
{code}
The problem is that with specified public_fields it's possible to retrieve all
user's names no matter has their public field or not. This behaviour a bit
violates implemented [System Database
Security|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e5503ff]:
[CouchDB 1.2.0 release
notes|https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0]:
{quote}
Documents in the _users database can no longer be read by everyone
Documents in the _users databases can now only be read by the respective
authenticated user and administrators. Before, all docs were world-readable
including their password hashes and salts.
{quote}
[Security Features
Overview|http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication%20database]:
{quote}
In addition, the _users database is now treated different from other databases:
An anonymous user can only create a new document.
An authenticated user can only update their own document.
A server or database admin can access and update all documents.
Only server or database admins can create design documents and access views
and _all_docs and _changes.
{quote}
Expected behaviour when `public_fields` specified:
`_all_docs` should returns only those user docs, that are actually contains
public fields. Users that has no such fields has nothing to publish. If user
[jira] [Created] (COUCHDB-1839) Allow changes feed emit changes for user docs with public fields
Alexander Shorin created COUCHDB-1839:
-
Summary: Allow changes feed emit changes for user docs with public
fields
Key: COUCHDB-1839
URL: https://issues.apache.org/jira/browse/COUCHDB-1839
Project: CouchDB
Issue Type: Improvement
Reporter: Alexander Shorin
When `public_fields` is specified, it's possible to retrieve users docs via
`_all_docs` resource, but it's still not possible to listen their changes:
{code}
curl -v http://abc:cba@localhost:5984/_users/_changes
HTTP/1.1 401 Unauthorized
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Sat, 22 Jun 2013 00:11:11 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 70
Cache-Control: must-revalidate
{"error":"unauthorized","reason":"You are not a db or server admin."}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1839) Allow changes feed emit changes for user docs with public fields
[
https://issues.apache.org/jira/browse/COUCHDB-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-1839:
--
Component/s: HTTP Interface
> Allow changes feed emit changes for user docs with public fields
>
>
> Key: COUCHDB-1839
> URL: https://issues.apache.org/jira/browse/COUCHDB-1839
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Alexander Shorin
>
> When `public_fields` is specified, it's possible to retrieve users docs via
> `_all_docs` resource, but it's still not possible to listen their changes:
> {code}
> curl -v http://abc:cba@localhost:5984/_users/_changes
> HTTP/1.1 401 Unauthorized
> Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
> Date: Sat, 22 Jun 2013 00:11:11 GMT
> Content-Type: text/plain; charset=utf-8
> Content-Length: 70
> Cache-Control: must-revalidate
> {"error":"unauthorized","reason":"You are not a db or server admin."}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1840) Better check for public_field value
[
https://issues.apache.org/jira/browse/COUCHDB-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-1840:
--
Priority: Trivial (was: Major)
> Better check for public_field value
> ---
>
> Key: COUCHDB-1840
> URL: https://issues.apache.org/jira/browse/COUCHDB-1840
> Project: CouchDB
> Issue Type: Improvement
>Reporter: Alexander Shorin
>Priority: Trivial
>
> It's possible to run into issue COUCHDB-1838 and enable `public_fields`
> feature without actually specifying any public fields:
> {code}
> [couch_httpd_auth]
> public_field = ,
> {code}
> Because of [split
> code|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_users_db.erl;h=9b875ba56d02d398049bb828015a37d219bcf6fd;hb=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60#l118]:
> {code}
> strip_non_public_fields(#doc{body={Props}}=Doc) ->
> Public = re:split(couch_config:get("couch_httpd_auth", "public_fields",
> ""),
>"\\s*,\\s*", [{return, binary}]),
> Doc#doc{body={[{K, V} || {K, V} <- Props, lists:member(K, Public)]}}.
> {code}
> The parameter's value as comma (`,`) will produce empty Public list.
> Probably, it's better to check him for any members and/or strip all empty
> string members before counting `public_fields` parameter activated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1840) Better check for public_field value
Alexander Shorin created COUCHDB-1840:
-
Summary: Better check for public_field value
Key: COUCHDB-1840
URL: https://issues.apache.org/jira/browse/COUCHDB-1840
Project: CouchDB
Issue Type: Improvement
Reporter: Alexander Shorin
It's possible to run into issue COUCHDB-1838 and enable `public_fields` feature
without actually specifying any public fields:
{code}
[couch_httpd_auth]
public_field = ,
{code}
Because of [split
code|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_users_db.erl;h=9b875ba56d02d398049bb828015a37d219bcf6fd;hb=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60#l118]:
{code}
strip_non_public_fields(#doc{body={Props}}=Doc) ->
Public = re:split(couch_config:get("couch_httpd_auth", "public_fields", ""),
"\\s*,\\s*", [{return, binary}]),
Doc#doc{body={[{K, V} || {K, V} <- Props, lists:member(K, Public)]}}.
{code}
The parameter's value as comma (`,`) will produce empty Public list. Probably,
it's better to check him for any members and/or strip all empty string members
before counting `public_fields` parameter activated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
