Apache en tant que proxy inverse pour CouchDB

Question

Je pense à une application web qui utilise beaucoup CouchDB, au point où il serait très avantageux de servir autant que possible l'API HTTP native erlang. Pouvez-vous configurer Apache en tant que proxy inverse pour permettre à des GET externes d'être directement transmis à CouchDB, alors que PUT/POST sont envoyés à la logique interne de l'application (pour l'assainissement, l'authentification ...)? Ou est-ce imprudent - les options d'authentification intégrées de CouchDB semblent un peu faibles pour une application Web.

Merci

Answer 1

Votre question vieillit sans réponses, donc je vais ajouter ce « presque réponse ».

Nginx peut certainement rediriger différemment en fonction des demandes.

Ceci est, si vous êtes prêt à placer nginx à l'avant comme revproxy et placez apache et couchdb à la fois comme backends.

Answer 2

Vous ne voyez pas? OAuth et l'authentification par cookie ont été vérifiés dans le 4:

http://github.com/halorgium/couchdb/commit/335af7d2a9ce986f0fafa4ddac7fc1a9d43a8678

Aussi, si vous êtes tous intéressés à utiliser Erlang comme la langue du serveur, vous pourriez CouchDB proxy par webmachine:

http://blog.beerriot.com/2009/05/18/couchdb-proxy-webmachine-resource/

Answer 3

Vous pouvez utiliser mod_rewrite pour sélectivement des demandes de proxy basées sur la méthode HTTP.

Par exemple:

# Send all GET and HEAD requests to CouchDB 
RewriteCond %{REQUEST_METHOD} GET|HEAD 
RewriteRule /db/(.*) http://localhost:5984/mydb/_design/myapp/$1 [P] 

# Correct all outgoing Location headers 
ProxyPassReverse /db/ http://localhost:5984/mydb/_design/myapp/ 

Toute POST, PUT ou DELETE demandes seront traitées par Apache comme d'habitude, vous pouvez donc câbler mais votre niveau d'application que vous le feriez habituellement.

Answer 4

J'envisagerais d'utiliser la fonction de proxy inverse d'Apache mod_proxy. Créez une configuration d'hôte virtuel qui transmet certaines requêtes HTTP du serveur Web à CouchDB. Vous pouvez configurer des règles sur les chemins URI qui doit être transmis, etc.

Voir ce guide pour l'inspiration: http://macgyverdev.blogspot.se/2014/02/apache-web-server-as-reverse-proxy-and.html