Re: Bug in Password
You can reproduce it easily using curl or a web browser. If your username has an @ in it, you can't use URL authentication successfully even if you url encode the username. On Tue, Aug 24, 2010 at 12:49 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Aug 24, 2010 at 6:26 AM, Martin Murphy martin.mur...@whiteboard-it.com wrote: Couchdb does not properly url decode usernames and passwords in the url. This prevents the majority of non ASCII characters from being used in either the username and password . This is a pretty high priority bug imo. It prevents couchapp for working on complex passwords and there are no alternatives using complex passwords for replication. It also prevents the very common scenario of using email addresses for logins/usernames. (If the logins are to be used with replication). Thanks for everything. Wish my erlang were better, I would fix this myself. Mmm it is the role oof the client to decode url/password from the url and pass the right headers to servers. Which client are you using ? - benoit
Re: Bug in Password
On Tue, Aug 24, 2010 at 8:08 AM, Nathan Stott nrst...@gmail.com wrote: You can reproduce it easily using curl or a web browser. If your username has an @ in it, you can't use URL authentication successfully even if you url encode the username. At the end couchdb see only the headers. So maybe it's the way the user was saved in the doc. Can you check how it is saved compared to the pparam you pass in your client or browser ? - benoît
[jira] Closed: (COUCHDB-437) Make compression level configurable, and allow attachments to be compressed
[ https://issues.apache.org/jira/browse/COUCHDB-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-437. Resolution: Duplicate Make compression level configurable, and allow attachments to be compressed --- Key: COUCHDB-437 URL: https://issues.apache.org/jira/browse/COUCHDB-437 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Jason Davies Priority: Minor Attachments: couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch, couchdb-583-trunk-6th-try.patch As suggested by Adam Kocolosk in http://www.mail-archive.com/dev@couchdb.apache.org/msg02858.html The nice thing is that binary_to_term seems perfectly happy reading a mix of compressed and uncompressed binaries, which means the compression level can be a configuration parameter if we want it to be. gzip decompresses pretty quickly, so I'm guessing that reading a compressed DB will be faster than an uncompressed one. We'll have to measure it, though. Just thinking that space may be at a premium for some users and enabling compression could save them quite a bit of space depending on the data stored in docs. Compressing attachments could be beneficial too, and for particular use cases compression might increase read throughput due to needing less disk reads. As Adam says, we need to measure it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bug in Password
It's saved in couch like usern...@example.com I have saved users named nrst...@gmail.com for example and that's how it shows up in the name field in the user doc On Tue, Aug 24, 2010 at 4:43 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Aug 24, 2010 at 8:08 AM, Nathan Stott nrst...@gmail.com wrote: You can reproduce it easily using curl or a web browser. If your username has an @ in it, you can't use URL authentication successfully even if you url encode the username. At the end couchdb see only the headers. So maybe it's the way the user was saved in the doc. Can you check how it is saved compared to the pparam you pass in your client or browser ? - benoît
Re: Bug in Password
On Tue, Aug 24, 2010 at 3:32 PM, Nathan Stott nrst...@gmail.com wrote: It's saved in couch like usern...@example.com I have saved users named nrst...@gmail.com for example and that's how it shows up in the name field in the user doc On Tue, Aug 24, 2010 at 4:43 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Aug 24, 2010 at 8:08 AM, Nathan Stott nrst...@gmail.com wrote: You can reproduce it easily using curl or a web browser. If your username has an @ in it, you can't use URL authentication successfully even if you url encode the username. At the end couchdb see only the headers. So maybe it's the way the user was saved in the doc. Can you check how it is saved compared to the pparam you pass in your client or browser ? - benoît I think it should be org.couchdb.user:username as id in user db. Need to check though. - benoit
Re: replication bug
Hi Nathan, did you get a chance to see if https://issues.apache.org/jira/browse/COUCHDB-868 fixed this issue? Adam On Aug 23, 2010, at 3:57 PM, Nathan Stott wrote: I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
Re: couch_db_update_notifier_sup started as worker?
On Aug 21, 2010, at 4:48 PM, Eric Carlson wrote: Having once been the kind of child who takes their toys apart in order to figure out how they work, and also having been a Prolog hacker in one of my former lives, I've foolishly started to go through the Erlang code for CouchDB (with the hope that I might one day be able to contribute something more useful to the project than merely verifying that release candidates build successfully ;-) ). In walking through what happens at application startup I found that couch_db_update_notifier_sup (a supervisor behaviour) is started as a worker process in couch_server_sup:start_secondary_services/0. Since I cannot (yet) claim to fully understand the world of OTP behaviours, I don't know how much this matters, but in case it does, I thought it worth bringing to the attention of those of you who know more than I do. Cheers, Eric Hi Eric, thanks. I've noticed this before too. It doesn't seem to be a huge deal at the moment, but it is something that should be corrected eventually, along with a handful of other OTP oddities. Best, Adam
[jira] Created: (COUCHDB-869) commonjs implementation creates circular references in the design document
commonjs implementation creates circular references in the design document -- Key: COUCHDB-869 URL: https://issues.apache.org/jira/browse/COUCHDB-869 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 1.0.2 Attachments: commonjs_circular_ref.diff this prevents JSON.stringify(this) from working in show functions, as the JSON.stringify function gets too much recursion. The culprit is the parent references created by our CommonJS implementation. test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson updated COUCHDB-869: --- Attachment: commonjs_circular_ref.diff test case for design doc circular references commonjs implementation creates circular references in the design document -- Key: COUCHDB-869 URL: https://issues.apache.org/jira/browse/COUCHDB-869 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 1.0.2 Attachments: commonjs_circular_ref.diff this prevents JSON.stringify(this) from working in show functions, as the JSON.stringify function gets too much recursion. The culprit is the parent references created by our CommonJS implementation. test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901926#action_12901926 ] J Chris Anderson commented on COUCHDB-869: -- I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io commonjs implementation creates circular references in the design document -- Key: COUCHDB-869 URL: https://issues.apache.org/jira/browse/COUCHDB-869 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 1.0.2 Attachments: commonjs_circular_ref.diff this prevents JSON.stringify(this) from working in show functions, as the JSON.stringify function gets too much recursion. The culprit is the parent references created by our CommonJS implementation. test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-869) commonjs implementation creates circular references in the design document
[ https://issues.apache.org/jira/browse/COUCHDB-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J Chris Anderson updated COUCHDB-869: - Comment: was deleted (was: I just had a beautiful baby girl named Irma, so I don't plan to respond to mail, except occasionally if it's a fun one. If you have an urgent request, please CC he...@couch.io and we'll make sure someone reads it. Thanks, Chris PS. Please let me know if this responder is hitting mailing lists, that would be lame. -- Chris Anderson http://jchrisa.net -- couch.io ) commonjs implementation creates circular references in the design document -- Key: COUCHDB-869 URL: https://issues.apache.org/jira/browse/COUCHDB-869 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 1.0.2 Attachments: commonjs_circular_ref.diff this prevents JSON.stringify(this) from working in show functions, as the JSON.stringify function gets too much recursion. The culprit is the parent references created by our CommonJS implementation. test attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bug in Password
That is the id, but I was referring to the name field.
{
_id: org.couchdb.user:nrst...@gmail.com,
_rev: 1-fbc8402aa4d61bf0acd04ab8763760e4,
name: nrst...@gmail.com,
type: user,
roles: [
]
}
That's the actual document.
On Tue, Aug 24, 2010 at 8:44 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Aug 24, 2010 at 3:32 PM, Nathan Stott nrst...@gmail.com wrote:
It's saved in couch like usern...@example.com
I have saved users named nrst...@gmail.com for example and that's
how it shows up in the name field in the user doc
On Tue, Aug 24, 2010 at 4:43 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Aug 24, 2010 at 8:08 AM, Nathan Stott nrst...@gmail.com wrote:
You can reproduce it easily using curl or a web browser. If your
username has an @ in it, you can't use URL authentication successfully
even if you url encode the username.
At the end couchdb see only the headers. So maybe it's the way the
user was saved in the doc. Can you check how it is saved compared to
the pparam you pass in your client or browser ?
- benoît
I think it should be org.couchdb.user:username as id in user db. Need
to check though.
- benoit
Re: replication bug
I tried it, didn't fix my issue. On Tue, Aug 24, 2010 at 9:38 AM, Adam Kocoloski kocol...@apache.org wrote: Hi Nathan, did you get a chance to see if https://issues.apache.org/jira/browse/COUCHDB-868 fixed this issue? Adam On Aug 23, 2010, at 3:57 PM, Nathan Stott wrote: I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
[jira] Created: (COUCHDB-870) CLONE -testsuite in couchdbx (1.0.0.8) crashes on MacOS 10.6.4
CLONE -testsuite in couchdbx (1.0.0.8) crashes on MacOS 10.6.4 -- Key: COUCHDB-870 URL: https://issues.apache.org/jira/browse/COUCHDB-870 Project: CouchDB Issue Type: Bug Components: Test Suite Affects Versions: 1.0 Environment: Mac OS 10.6.4 on MacBook Pro 4GByte, CouchDBX Reporter: Grant Jones several tests of the testsuite crash on MacOS (whereas they run on Ubuntu within a VM on my machine). FOr example, attachment test fails with out of memory error, afterwards CouchDBX does not respond to any input. Please tell me what further info you need to investigate! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-870) CLONE -testsuite in couchdbx (1.0.0.8) crashes on MacOS 10.6.4
[
https://issues.apache.org/jira/browse/COUCHDB-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901981#action_12901981
]
Grant Jones commented on COUCHDB-870:
-
This is an issue with line 271 of the attachments.js test not having a
semicolon at the end. Looking at past issues this sort of bug seems to have
happened in the past. To make this less severe for safari users adding if(i ==
-1) { break; } to line 37 of couch_test_runner.js would exit that infinite
loop.
CLONE -testsuite in couchdbx (1.0.0.8) crashes on MacOS 10.6.4
--
Key: COUCHDB-870
URL: https://issues.apache.org/jira/browse/COUCHDB-870
Project: CouchDB
Issue Type: Bug
Components: Test Suite
Affects Versions: 1.0
Environment: Mac OS 10.6.4 on MacBook Pro 4GByte, CouchDBX
Reporter: Grant Jones
several tests of the testsuite crash on MacOS (whereas they run on Ubuntu
within a VM on my machine).
FOr example, attachment test fails with out of memory error, afterwards
CouchDBX does not respond to any input.
Please tell me what further info you need to investigate!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
