We return a 401 with {"error":"unauthorized","reason":"Name or
password is incorrect."} for the case when the username does not match
a valid user and the case where the username matches but the password
does not.If you do find a gap in this, please email [email protected]. B. On 22 March 2013 13:58, svilen <[email protected]> wrote: > fine. i meant that if i'm about to try guess some couchdb server > users, if wrongusr:wrongpsw@SRV/_session is "revealing" the 401 then > there's no point in hiding wrongusr:wrongpsw@SRV/_users/wrongusr behind > 404. it's a weak "protection". > but anyway.. nevermind. > > On Fri, 22 Mar 2013 13:43:49 +0000 > Robert Newson <[email protected]> wrote: > >> returning 404 for /_session would be saying that /_session doesn't >> exist unless you have credentials. This goes too far, there's nothing >> secret about the existence of the /_session endpoint. >> >> Compare to GitHub. They return a 404 for any /accountname/projectname >> that doesn't exist at all, and they return 404 for any >> /accountname/projectname that *does* exist but is private. From the >> point of view of someone without authorization to see that project >> it's effectively not there. Returning 404 in the first case and 401 in >> the second case would reveal information that should not be revealed. >> >> In the users db case, the resource at >> /_users/name_of_someone_that_isn't_me is 404 unless you are allowed to >> see it, for the same reason. >> >> B. >> >> On 22 March 2013 13:36, svilen <[email protected]> wrote: >> > hmm >> > shouldnt then /_session behave same? >> > it returns 401 >> > >> > On Fri, 22 Mar 2013 13:24:28 +0000 >> > Robert Newson <[email protected]> wrote: >> > >> >> Sure, and it's deliberately not helpful; >> >> >> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 >> >> >> >> "This status code is commonly used when the server does not wish to >> >> reveal exactly why the request has been refused..." >> >> >> >> Returning 401 vs 404 would reveal which user names exist. >> >> >> >> B. >> >> >> >> On 22 March 2013 13:20, svilen <[email protected]> wrote: >> >> > that's fine. just the error isn't very helpful.. >> >> > and the browsers don't play nice. >> >> > anyway >> >> > >> >> >> That's by design. In 1.2.0 you can only see your own user >> >> >> document. >> >> >> >> >> >> B. >> >> >> >> >> >> On 22 March 2013 13:03, svilen <[email protected]> wrote: >> >> >> > g'day >> >> >> > i am playing with the plain user:psw auth in url, and it gives >> >> >> > funny results. at least to me.. (couchdb 1.2.0 in latest >> >> >> > ubuntu) >> >> >> > >> >> >> > i register some user, say name=a/psw=b. >> >> >> > >> >> >> > with auth: >> >> >> > $ curl GET http://a:b@/_users/org.couchdb.user:a >> >> >> > is fine >> >> >> > >> >> >> > without auth: >> >> >> > $ curl GET http://_users/org.couchdb.user:a >> >> >> > returns 404 {"error":"not_found","reason":"missing"} >> >> >> > >> >> >> > now with auth, but in browsers: >> >> >> > - opera http://a:b@/_users/org.couchdb.user:a works >> >> >> > - firefox http://a:b@/_users/org.couchdb.user:a warns about >> >> >> > "server not needing authentication".. and strips the usr/psw >> >> >> > yielding 404 >> >> >> > - iexplorer - 404 - strips unconditionaly >> >> >> > >> >> >> > is this something that is expected to be so? >> >> >> > maybe the error can be changed (to 401) ? >> >> >> > >> >> >> > i don't know that part about the "server not needing >> >> >> > authentication" .. maybe something in the headers ? or some >> >> >> > config of couch_httpd_auth ? >> >> >> > >> >> >> > ciao >> >> >> > svilen
