[ 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