I posted this question on DBA, but it got closed and was never reopened even after I rewrote the whole thing to be more specific. I think its more appropriate for programmers anyway :)

Background Information

I have a CouchDB server (Server B) that is accessed by another server running PHP (Server A). My web app (Client-side Javascript) makes a request for a file to Server A. Server A sends requests to Server B with the access credentials (username:password). Server B returns JSON objects that correspond to matched files, then Server A returns that data to the client. The response includes some meta data about the file and a URL to the file on Server B. The actual file data itself is not included in the response.

The Problem

The URL to the document attachment included in the JSON response from Server B includes access credentials (username:password). Server A responds to the client-side request by returning those JSON objects.

The client now has this information:


Currently all data contained within Server B resides in one database instance. If the client has access to the username:password to the CouchDB then all data could be queried with those access credentials. Like so,


Server-side considerations

CouchDB on Cloudant

Client-side considerations

The Javascript running on the client requires a URL string to the file. The files that are being referenced are KML layers for Google Maps. A new KML layer is created using this constructor.

What I am looking for

Essentially my solution would come if I can provide a link to a CouchDB document attachment without giving the username/password.


What I did

I had to enable cURL for PHP on Server A.

sudo apt-get install curl libcurl3 libcurl3-dev php5-curl
sudo /etc/init.d/apache2 restart

Got a bit of code from David Walsh's blog.

My Javascript client code gets a list of JSON file meta data from Server A. This data includes unique DB IDs and file names (No passwords or API keys). I then pass the document ID and filename to another service on Server A which echoes the value of,

get_data('https://username:password@Server B:port/dbname/path/to/file.whatever');

I can now serve out the files to the client without revealing username or password for CouchDB on Server B.

2 Answers 2


I don't think you'll be able to do what you want without opening up all the CouchDB documents to all-comers.

The solution is, I believe, to only send back to the client this portion of the returned document URL:


And then keep your client talking with Server A:

https://Server A/get_document/dbname/path/to/file.whatever

Server A then just translates this to the return form Server B:


That way the client never needs to know about Server B, and Server B can be locked down away from prying eyes.

  • sounds like a plan! I will try that out today.
    – cs_brandt
    Commented May 22, 2012 at 20:32

It sounds like you want the documents the end user to receive to be served up directly from the database server. In general, thats a bad idea. Particularly if this is a public facing application. Better to insolate the database they way you have it now. Is there a particular reason you feel that the db needs to directly hand the client the document?

I would keep everything in your middleware application, and have that handle the document delivery. Or if you must, create a separate server application that only handles the document transfer between the client and db. The client would request a document URL, and your app server would fetch it from the db and return it to the client for them.

  • errr, maybe my terminology is off, there are 2 servers. One runs my PHP that has a set of services for accessing data on the CouchDB server. These services connect to CouchDB with the API key and password then send the applicable data back to the client. The API key and password are held on the PHP server, so that server is the only computer that can directly access CouchDB (Unless I login manually). Let me know what I can clarify to make this clearer, thanks.
    – cs_brandt
    Commented May 22, 2012 at 18:17
  • Please clarify (by editing your original question) what the problem is, and what the desired outcome should look like. You say the php app is only thing with access to the db, yet your question makes it sound like yuo are trying to access it from the client. Commented May 22, 2012 at 19:33
  • well the database is handing over the link to the document, I need the link for Google Maps. I dont really see an issue though having documents in that DB, in the future we might be doing client-side replication for field work. Having all the data and documents in the same container is convenient. Maybe you can point me to some material to support your opinions?
    – cs_brandt
    Commented May 22, 2012 at 20:37
  • I'm still missing something, I think. Whats the problem with having the PHP app handle the document fetching? Rather than 'host:port:/whatever', have the request look like 'myapp.php:port?doc=whatever'. Commented May 22, 2012 at 21:02
  • oh, im pretty sure then you and Peter K. are on track for the same solution. I will work it out here in the next couple of hours.
    – cs_brandt
    Commented May 22, 2012 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.