couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ari Najarian (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
Date Sat, 19 Nov 2011 20:26:51 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153577#comment-13153577
] 

Ari Najarian commented on COUCHDB-1175:
---------------------------------------

Marcello, Johannes, thanks for your suggestions. I'm actively looking for a workaround for
the time being.

I had considered the dual-database solution, where secure data is locked down in one db, and
the couchapp design document sits on a separate database. I had a few (4) misgivings about
this approach, though. 

1. If I'm using AJAX to pull in data from the secure database, I would either have to use
jQuery.couch.js to authenticate (meaning the credentials are stored in the code), or I'd have
to provide a login prompt to authenticate the user and retrieve a session-based cookie so
that requests to the secure database return documents. 

The former case is not secure, as anybody can view source and pull the login credentials that
I'm using to unlock the database. The latter might work, but I struggle with how to handle
the situation when the cookie expires. I'm building a mobile couchapp, so the user might return
after several hours to check for new data. When the AJAX request is fired off, we come up
against the same problem of a JSON response being returned. Are you suggesting that I intercept
this response and display a prompt to the user to re-authenticate?

2. Perhaps most importantly, if the entire couchapp is built using AJAX, am I able to benefit
from any of the view, shows, templates and partials that are features of couchDB? Design documents,
as far as I understand, are walled gardens, so relative paths end up at the root of _design/couchapp.
Is there a way, without using absolute paths, to reference a show or list function in another
design document in another database? Absolute paths to a show function would be problematic:
if the couchapp is ever replicated to server B, it would still look for the show function
on server A.

3. Related to the previous point, using AJAX to re-authenticate and pull in data from a separate
design document would basically mean that JS is now acting as another layer on the stack -
not the most elegant solution, as the whole architecture of couchapp is supposed to be self-contained.

4. Writing a jQuery mobile app that lives in a database separate from the actual documents
it serves would require me to replicate two separate databases to a new server, correct? If
so, this is again inelegant, as the couchapp isn't self-contained anymore.


I'm not bringing up these points to whine or complain. I'm just trying to make sure I move
forward in the best way possible. My understanding of cocuhDB is still a little shaky, so
if there are any misconceptions in my statements above, I'd appreciate clarification. As it
stands, I'm going to migrate my jQuery mobile couchapp to a separate design document in a
separate database, and make absolute calls to the views and shows I build in a sibling database's
design document in order to populate the pages of the couchapp.

I hope that makes sense. Please stop me if I'm doing it wrong!
                
> Improve content type negotiation for couchdb JSON responses
> -----------------------------------------------------------
>
>                 Key: COUCHDB-1175
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1175
>             Project: CouchDB
>          Issue Type: Improvement
>    Affects Versions: 1.0.2
>            Reporter: Robert Newson
>            Priority: Blocker
>             Fix For: 1.2
>
>
> Currently we ignore qvalues when negotiation between 'application/json' and 'text/plain'
when returning JSON responses.
> Specifically, we test directly for 'application/json' or 'text/plain' in the Accept header.
Different branches have different bugs, though. Trunk returns 'application/json' if 'application/json'
is present at all, even if it's less preferred than 'text/plain' when qvalues are accounted
for.
> We should follow the standard.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message