Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9r=u5t1nZMwZpOfBdL-bCEcWY1eXWrvYETTEckUbEnLjw@mail.gmail.com>
References: <1397424531.24083.YahooMailNeo@web181703.mail.ne1.yahoo.com>
	<CAO5PmOqs5kg+SAT2eXdZmVes1Y+R2f5--6ivoXxoXX9QxLK6hA@mail.gmail.com>
	<1397484841.28230.YahooMailNeo@web181702.mail.ne1.yahoo.com>
	<CAJNb-9pwtQoc49vk95d8W9t8-XGYV=bdBX4eVoyiA=EUaBa29g@mail.gmail.com>
	<1397490947.60337.YahooMailNeo@web181703.mail.ne1.yahoo.com>
	<CAJNb-9rrm1ikBb481RaWX6NiXN0gsirQumd-eN-CfyfBVyOyZw@mail.gmail.com>
	<1397495480.49460.YahooMailNeo@web181704.mail.ne1.yahoo.com>
	<CAJNb-9oSgJ6iVbXi1n3+-hWu4voJLcicqtS+9oaPd6RfEF-RbQ@mail.gmail.com>
	<1397829369.80661.YahooMailNeo@web181706.mail.ne1.yahoo.com>
	<CAJNb-9r=u5t1nZMwZpOfBdL-bCEcWY1eXWrvYETTEckUbEnLjw@mail.gmail.com>
Date: Sat, 19 Apr 2014 12:51:16 +0200
Message-ID: 
 <CAO5PmOrSEXykd_m4jhKTSkgBwmtVtQAnThB0QAnw-UGnezsvwA@mail.gmail.com>
Subject: Re: authentication_redirect is not working.
From: =?UTF-8?Q?Johannes_J=C3=B6rg_Schmidt?= <schmidt@netzmerk.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b2e548aafed9104f7630b6f

--047d7b2e548aafed9104f7630b6f
Content-Type: text/plain; charset=UTF-8

We have vhosts and rewrites like this in production for years and it works
like a charm.
If you unterstand CouchDBs security model nothing speaks against opening
its API to the world.

Greetings
Johannes
Am 19.04.2014 06:41 schrieb "Benoit Chesneau" <bchesneau@gmail.com>:

> On Fri, Apr 18, 2014 at 3:56 PM, Scott Weber <scotty2541@sbcglobal.net
> >wrote:
>
> > Yes, I tried to implement the vhost and redirect. vhost was behaving as
> > documented. The redirect was not. There was no change in behavior.
> >
>
> I have just tested this rule:
>
>   [{
>
>         "from": "/",
>         "to": "index.html"
>     },
>     {
>
>         "from": "/*",
>
>         "to": "*"
>     },
>     ... other rules to access to dbs
> ]
>
>
>
> and set the vhost to the /db/ddoc/_rewrites
>
> and it was working as expected
>
>
> >
> > The purpose is that I was led to believe that this server would eliminate
> > the need for a public facing general web server. As such, real domains
> show
> > you actual content at their root level, not a dry "welcome to couchdb"
> > message.
> >
>
> > I can see that this is not such a good idea, for a number of reasons.
> > Fortunately I have already placed it in a farm behind a formal server,
> and
> > can control access through rewrites and server side scripts. It turned
> into
> > a classic example of using a tool for what it is good at, not trying to
> > make it into something it is not designed for.
> >
> >
> The rule above works. I did it a lot f time. Now the only part that is
> really missing of the equation is the security. If you want to prevent
> people to go on the root you will need to use a proxy on top.
>
> - benoit
>

--047d7b2e548aafed9104f7630b6f--