fyi: I had no trouble deleting my own user document;
➜ ~ curl
'foo:bar@localhost:5984/_users/org.couchdb.user:foo?rev=1-f77e70173079dbbf2f5f2ea1075ca5a7'
-XDELETE
{"ok":true,"id":"org.couchdb.user:foo","rev":"2-efdf988662f5577cf4ce6213bcf5f832"}
➜ ~ curl 'admin:admin@localhost:5984/_users/org.couchdb.user:foo'
{"error":"not_found","reason":"deleted"}
B.
On 23 April 2013 15:29, Robert Newson <rnew...@apache.org> wrote:
> _deleted:true is exactly the same as DELETE to couchdb. It's curious
> we block one and not the other, so I guess that's just a mistake. The
> injected ddoc specifically allows a user to delete their own document.
>
> if (newDoc._deleted === true) {
> // allow deletes by admins and matching users
> // without checking the other fields
> if ((userCtx.roles.indexOf('_admin') !== -1) ||
> (userCtx.name == oldDoc.name)) {
> return;
> } else {
> throw({forbidden: 'Only admins may delete other user docs.'});
> }
> }
>
>
> Also this is no longer on topic. :D
>
> B.
>
> On 23 April 2013 15:25, svilen <a...@svilendobrev.com> wrote:
>> ah.
>> i'll be updating the userdoc with _deleted=true then, it does all the
>> job including showing as delete in _changes. well, yet another
>> workaround.
>>
>> ciao
>> svilen
>>
>> On Tue, 23 Apr 2013 10:00:20 -0400
>> Mike West <m...@data.io> wrote:
>>
>>> +1 as a security feature, not a bug.
>>>
>>> Mike
>>>
>>>
>>> On Tue, Apr 23, 2013 at 9:26 AM, Robert Newson <rnew...@apache.org>
>>> wrote:
>>>
>>> > svilen,
>>> >
>>> > I don't think that's considered a bug, though. Admins can delete
>>> > users, users can't delete themselves. We can certainly debate that,
>>> > but I think our position is that this is intentional.
>>> >
>>> > I'm also backporting the configure.ac fix as it makes it hard to
>>> > run my tests.
>>> >
>>> > B.
>>> >
>>> > On 23 April 2013 14:19, svilen <a...@svilendobrev.com> wrote:
>>> > > the one of user unable to DELETE itself, from the other day..
>>> > > don't know if it has been fixed or not.
>>> > >
>>> > > On Tue, 23 Apr 2013 14:14:23 +0100
>>> > > Noah Slater <nsla...@apache.org> wrote:
>>> > >
>>> > >> Any other bugs while we're at it. I'll be sending out a formal
>>> > >> request tonight for people to do merges. But may as well mention
>>> > >> it now.
>>> > >>
>>> > >>
>>> > >> On 23 April 2013 14:11, Robert Newson <rnew...@apache.org> wrote:
>>> > >>
>>> > >> > good thought.
>>> > >> >
>>> > >> > On 23 April 2013 14:07, Noah Slater <nsla...@apache.org> wrote:
>>> > >> > > Can we put this into one or more of the bugfixes branches?
>>> > >> > >
>>> > >> > >
>>> > >> > > On 23 April 2013 14:02, Robert Newson <rnew...@apache.org>
>>> > >> > > wrote:
>>> > >> > >
>>> > >> > >> I believe the fix for this is 5d4ef930 which is on master
>>> > >> > >> (which will be 1.4) only.
>>> > >> > >>
>>> > >> > >> specifically;
>>> > >> > >>
>>> > >> > >> - [Name, Pass] = re:split(NamePass, ":", [{return,
>>> > >> > >> list}]),
>>> > >> > >> + [Name, Pass] = re:split(NamePass, ":", [{return,
>>> > >> > >> list}, {parts, 2}]),
>>> > >> > >>
>>> > >> > >> B.
>>> > >> > >>
>>> > >> > >>
>>> > >> > >>
>>> > >> > >>
>>> > >> > >> On 23 April 2013 13:59, Robert Newson <rnew...@apache.org>
>>> > >> > >> wrote:
>>> > >> > >> > Ah, that's a great distinction, rings a bell!
>>> > >> > >> >
>>> > >> > >> > On 23 April 2013 13:39, Dave Cottlehuber
>>> > >> > >> > <d...@jsonified.com> wrote:
>>> > >> > >> >> On 23 April 2013 13:15, svilen <a...@svilendobrev.com>
>>> > >> > >> >> wrote:
>>> > >> > >> >>> g'day
>>> > >> > >> >>>
>>> > >> > >> >>> i am trying to set a user with a password that is not
>>> > >> > >> >>> just
>>> > >> > >> alphanumeric.
>>> > >> > >> >>> e.g. "b:@" (or if uri-encoded, b%3A%40)
>>> > >> > >> >>>
>>> > >> > >> >>> but the result of getting the /_users/ doc is always
>>> > >> > 401-unauthorized.
>>> > >> > >> >>>
>>> > >> > >> >>> if i login in Futon, it seems to work.
>>> > >> > >> >>> when i compute the pasword_sha myself and compare to
>>> > >> > >> >>> whats in
>>> > >> > user/doc,
>>> > >> > >> >>> it matches.
>>> > >> > >> >>>
>>> > >> > >> >>> but http via basic authentication won't let me in.
>>> > >> > >> >>> e.g.
>>> > >> > >> >>> curl -vX GET
>>> > >> > >> >>> http://auser:b%3A%40@server
>>> > :5984/_users/org.couchdb.user%3Aauser
>>> > >> > >> >>>
>>> > >> > >> >>> (seems the subject is very tricky and rarely paid
>>> > >> > >> >>> attention to in various http libraries i looked
>>> > >> > >> >>> recently. Everyone just lumps the usr+":"+psw and
>>> > >> > >> >>> uri-encoding/decoding is left out..)
>>> > >> > >> >>
>>> > >> > >> >> Hi Svilen,
>>> > >> > >> >>
>>> > >> > >> >> From curl, you can:
>>> > >> > >> >>
>>> > >> > >> >> curl -vX GET $COUCH -u tricky:p@sswd
>>> > >> > >> >>
>>> > >> > >> >> and leaving off the password field allows you to enter it
>>> > >> > >> >> manually or even echo ':p@sswd' | curl …
>>> > >> > >> >>
>>> > >> > >> >> or if you're POSTing I think you can also use this:
>>> > >> > >> >> http://curl.haxx.se/docs/manpage.html#--data-urlencode
>>> > >> > >> >>
>>> > >> > >> >> curl -d name=john --data-urlencode passwd=@31&3*J
>>> > >> > >> https://www.mysite.com
>>> > >> > >> >>
>>> > >> > >> >> Anyway AFAICT there's a bug in CouchDB if the password
>>> > >> > >> >> starts with a
>>> > >> > `:`
>>> > >> > >> >>
>>> > >> > >> >> $COUCH=http://admin:pwd@localhost:5984
>>> > >> > >> >>
>>> > >> > >> >> curl -HContent-Type:application/json \
>>> > >> > >> >> -vXPUT $COUCH/_users/org.couchdb.user:mrtricky \
>>> > >> > >> >> --data-binary '{"_id":
>>> > >> > >> >> "org.couchdb.user:mrtricky","name": "mrtricky","roles":
>>> > >> > >> >> [],"type": "user","password": ":pwd"}'
>>> > >> > >> >>
>>> > >> > >> >> I would expect that I can subsequently use either curl or
>>> > >> > >> >> httpie.org
>>> > >> > ,
>>> > >> > >> >> neither of them succeed with -u mrtricky::pwd or -u
>>> > >> > >> >> mrtricky &
>>> > >> > getting
>>> > >> > >> >> password from terminal.
>>> > >> > >> >>
>>> > >> > >> >> A+
>>> > >> > >> >> Dave
>>> > >> > >>
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >> > > --
>>> > >> > > NS
>>> > >> >
>>> > >>
>>> > >>
>>> > >>
>>> > >> --
>>> > >> NS
>>> >
