[
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
