You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Marcello Nuccio <ma...@gmail.com> on 2011/06/17 14:28:14 UTC
Bug parsing Accept header?
Trying to debug why the configuration option `authentication_redirect`
did stopped working in CouchDB-1.1, I have finally nailed it down to a
simple use-case.
You can reproduce it with the following commands (assuming you have
setup and admin user with name "admin" and password "pass":
$ curl -X PUT 'http://admin:pass@localhost:5984/testauth'
{"ok":true}
$ cat security.json
{"admins":{"names":["boutique"],"roles":[]},"readers":{"names":[],"roles":["azienda"]}}
$ curl -X PUT 'http://admin:pass@localhost:5984/testauth/_security' -d
@security.json -H 'Content-Type: application/json; charset=UTF-8'
{"ok":true}
$ curl -D- 'http://admin:pass@localhost:5984/testauth'
HTTP/1.1 200 OK
Server: CouchDB/1.1.0 (Erlang OTP/R14B03)
Date: Fri, 17 Jun 2011 11:56:32 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 215
Cache-Control: must-revalidate
{"db_name":"testauth","doc_count":0,"doc_del_count":0,"update_seq":1,"purge_seq":0,"compact_running":false,"disk_size":4171,"instance_start_time":"1308310604678421","disk_format_version":5,"committed_update_seq":1}
$ curl -D- 'http://localhost:5984/testauth'
HTTP/1.1 401 Unauthorized
Server: CouchDB/1.1.0 (Erlang OTP/R14B03)
Date: Fri, 17 Jun 2011 11:56:44 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 78
Cache-Control: must-revalidate
{"error":"unauthorized","reason":"You are not authorized to access this db."}
$ curl -D- 'http://localhost:5984/testauth' -H 'Accept: text/html,*/*;q=0.0'
HTTP/1.1 302 Moved Temporarily
Server: CouchDB/1.1.0 (Erlang OTP/R14B03)
Location: http://localhost:5984/cerbero/_design/cerbero/login.html?return=%2Ftestauth&reason=You%20are%20not%20authorized%20to%20access%20this%20db.
Date: Fri, 17 Jun 2011 11:57:41 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 78
Cache-Control: must-revalidate
{"error":"unauthorized","reason":"You are not authorized to access this db."}
$ curl -D- 'http://localhost:5984/testauth' -H 'Accept: text/html,*/*;q=0.1'
HTTP/1.1 401 Unauthorized
Server: CouchDB/1.1.0 (Erlang OTP/R14B03)
Date: Fri, 17 Jun 2011 11:57:55 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 78
Cache-Control: must-revalidate
{"error":"unauthorized","reason":"You are not authorized to access this db."}
This last one should give you the same "302 Moved Temporarily"
response as the previous one, because we accept "text/html".
The problem is that Firefox uses a similar Accept header, so it gets a
401 Unauthorized error instead of being redirected to the login page.
I think the problem was introduced by this commit:
https://github.com/apache/couchdb/commit/0264c51de7f281bc3b01d51e43831da2bcc741df
Is this a bug, or is intended behaviour?
Thanks,
Marcello
Re: Bug parsing Accept header?
Posted by Robert Newson <ro...@gmail.com>.
Reproduced locally. From here on, let's stick to commenting via the 1175 ticket.
The change was deliberate but has unintended side-effects. I'm
currently +1 on reverting this change in 1.1.1, but I'd like to
finally nail the exact semantics for this content-type negotiation
once and for all.
B.
On 17 June 2011 16:32, Marcello Nuccio <ma...@gmail.com> wrote:
> 2011/6/17 Robert Newson <ro...@gmail.com>:
>> Hi Marcello,
>>
>> The current logic for CouchDB 1.1.0 is this;
>>
>> 1) If the client accepts "application/json" then respond with 401 and
>> content-type "application/json" (i.e, a normal HTTP/REST response.
>> 2) if the client accepts "text/html" then respond with a 302 to the
>> authentication_redirect url.
>>
>> This is from couch_httpd:error_headers/4.
>
> I have responded here:
> https://issues.apache.org/jira/browse/COUCHDB-1175?focusedCommentId=13051132&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13051132
>
>
>> I'll note that Futon does not produce login popups under the
>> conditions you describe but perhaps I failed to reproduce your test
>> scenario (in Firefox 4.0.1, anyway).
>
> Did you setup a security object with "admins" and "readers" for the DB?
>
> If you are not logged in, Futon should display an alert with:
>
> Error: unauthorized
> You are not authorized to access this db.
>
> This is the same behaviour as CouchDB-1.0.
>
> The problem is when you try to access a couchapp in the protected DB.
> Since you are not redirected to a login page, you get stuck with a
> access denied error.
>
> Hope I have been clear... my English is very basic... sorry.
>
> Marcello
>
Re: Bug parsing Accept header?
Posted by Marcello Nuccio <ma...@gmail.com>.
2011/6/17 Robert Newson <ro...@gmail.com>:
> Hi Marcello,
>
> The current logic for CouchDB 1.1.0 is this;
>
> 1) If the client accepts "application/json" then respond with 401 and
> content-type "application/json" (i.e, a normal HTTP/REST response.
> 2) if the client accepts "text/html" then respond with a 302 to the
> authentication_redirect url.
>
> This is from couch_httpd:error_headers/4.
I have responded here:
https://issues.apache.org/jira/browse/COUCHDB-1175?focusedCommentId=13051132&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13051132
> I'll note that Futon does not produce login popups under the
> conditions you describe but perhaps I failed to reproduce your test
> scenario (in Firefox 4.0.1, anyway).
Did you setup a security object with "admins" and "readers" for the DB?
If you are not logged in, Futon should display an alert with:
Error: unauthorized
You are not authorized to access this db.
This is the same behaviour as CouchDB-1.0.
The problem is when you try to access a couchapp in the protected DB.
Since you are not redirected to a login page, you get stuck with a
access denied error.
Hope I have been clear... my English is very basic... sorry.
Marcello
Re: Bug parsing Accept header?
Posted by Robert Newson <ro...@gmail.com>.
Hi Marcello,
The current logic for CouchDB 1.1.0 is this;
1) If the client accepts "application/json" then respond with 401 and
content-type "application/json" (i.e, a normal HTTP/REST response.
2) if the client accepts "text/html" then respond with a 302 to the
authentication_redirect url.
This is from couch_httpd:error_headers/4.
I'll note that Futon does not produce login popups under the
conditions you describe but perhaps I failed to reproduce your test
scenario (in Firefox 4.0.1, anyway).
B.
On 17 June 2011 15:23, Marcello Nuccio <ma...@gmail.com> wrote:
> Hi Robert, thanks for your help.
>
> The problem I have is: host a couchapp in a password protected DB.
> This is why I need authentication_redirect.
>
> If I understand it correctly, the logic is:
>
> - if the client accepts "text/html", then respond with "302";
> - if not, then respond with "401".
>
> What is the difference between
> Accept: text/html,*/*;q=0.0
> and
> Accept: text/html,*/*;q=0.1
> ?
>
> I think they should be treated the same way in this use-case.
> What am I missing?
>
> thanks,
> Marcello
>
> 2011/6/17 Robert Newson <rn...@apache.org>:
>> Actualy I think it's this d952ac01cb4cd4ae5ceb0c8cc079acf595ff9747,
>> which is part of COUCHDB-1175.
>>
>> I note that I dislike this content-type negotiation quite a lot, no
>> combination appears to satisfy everyone.
>>
>> B.
>>
>> https://issues.apache.org/jira/browse/COUCHDB-1175
>>
>> On 17 June 2011 13:53, Marcello Nuccio <ma...@gmail.com> wrote:
>>> Follow-up:
>>>
>>> To make it work like in CouchDB-1.0, I have tried to change Firefox
>>> Accept header.
>>>
>>> From the "about:config" page, I have set "network.http.accept.default" to
>>> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.0"
>>> from the default
>>> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
>>>
>>> i.e. I have changed the last character from "8" to "0".
>>>
>>> Now, Firefox is correctly redirected to the login page when accessing
>>> a password protected database.
>>>
>>> Does someone can confirm the same problem?
>>>
>>> Thanks,
>>> Marcello
>>>
>>
>
Re: Bug parsing Accept header?
Posted by Marcello Nuccio <ma...@gmail.com>.
2011/6/17 Benoit Chesneau <bc...@gmail.com>:
> Not sure if the ml is the right way to discuss this
> issue/improvement.Maybe we can start to collect all of this somewhere
> ?
>
> https://issues.apache.org/jira/browse/COUCHDB-1175 is a good candidate.
ok, I have posted a comment there.
Marcello
Re: Bug parsing Accept header?
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Jun 17, 2011 at 4:23 PM, Marcello Nuccio
<ma...@gmail.com> wrote:
> Hi Robert, thanks for your help.
>
> The problem I have is: host a couchapp in a password protected DB.
> This is why I need authentication_redirect.
>
> If I understand it correctly, the logic is:
>
> - if the client accepts "text/html", then respond with "302";
> - if not, then respond with "401".
>
> What is the difference between
> Accept: text/html,*/*;q=0.0
> and
> Accept: text/html,*/*;q=0.1
> ?
>
> I think they should be treated the same way in this use-case.
> What am I missing?
>
> thanks,
> Marcello
>
Not sure if the ml is the right way to discuss this
issue/improvement.Maybe we can start to collect all of this somewhere
?
https://issues.apache.org/jira/browse/COUCHDB-1175 is a good candidate.
- benoît
Re: Bug parsing Accept header?
Posted by Marcello Nuccio <ma...@gmail.com>.
Hi Robert, thanks for your help.
The problem I have is: host a couchapp in a password protected DB.
This is why I need authentication_redirect.
If I understand it correctly, the logic is:
- if the client accepts "text/html", then respond with "302";
- if not, then respond with "401".
What is the difference between
Accept: text/html,*/*;q=0.0
and
Accept: text/html,*/*;q=0.1
?
I think they should be treated the same way in this use-case.
What am I missing?
thanks,
Marcello
2011/6/17 Robert Newson <rn...@apache.org>:
> Actualy I think it's this d952ac01cb4cd4ae5ceb0c8cc079acf595ff9747,
> which is part of COUCHDB-1175.
>
> I note that I dislike this content-type negotiation quite a lot, no
> combination appears to satisfy everyone.
>
> B.
>
> https://issues.apache.org/jira/browse/COUCHDB-1175
>
> On 17 June 2011 13:53, Marcello Nuccio <ma...@gmail.com> wrote:
>> Follow-up:
>>
>> To make it work like in CouchDB-1.0, I have tried to change Firefox
>> Accept header.
>>
>> From the "about:config" page, I have set "network.http.accept.default" to
>> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.0"
>> from the default
>> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
>>
>> i.e. I have changed the last character from "8" to "0".
>>
>> Now, Firefox is correctly redirected to the login page when accessing
>> a password protected database.
>>
>> Does someone can confirm the same problem?
>>
>> Thanks,
>> Marcello
>>
>
Re: Bug parsing Accept header?
Posted by Robert Newson <rn...@apache.org>.
Actualy I think it's this d952ac01cb4cd4ae5ceb0c8cc079acf595ff9747,
which is part of COUCHDB-1175.
I note that I dislike this content-type negotiation quite a lot, no
combination appears to satisfy everyone.
B.
https://issues.apache.org/jira/browse/COUCHDB-1175
On 17 June 2011 13:53, Marcello Nuccio <ma...@gmail.com> wrote:
> Follow-up:
>
> To make it work like in CouchDB-1.0, I have tried to change Firefox
> Accept header.
>
> From the "about:config" page, I have set "network.http.accept.default" to
> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.0"
> from the default
> "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
>
> i.e. I have changed the last character from "8" to "0".
>
> Now, Firefox is correctly redirected to the login page when accessing
> a password protected database.
>
> Does someone can confirm the same problem?
>
> Thanks,
> Marcello
>
Re: Bug parsing Accept header?
Posted by Marcello Nuccio <ma...@gmail.com>.
Follow-up:
To make it work like in CouchDB-1.0, I have tried to change Firefox
Accept header.
>From the "about:config" page, I have set "network.http.accept.default" to
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.0"
from the default
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
i.e. I have changed the last character from "8" to "0".
Now, Firefox is correctly redirected to the login page when accessing
a password protected database.
Does someone can confirm the same problem?
Thanks,
Marcello