incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Weber <scotty2...@sbcglobal.net>
Subject Re: authentication_redirect is not working.
Date Sat, 19 Apr 2014 14:37:11 GMT
Ahh, a new piece of the puzzle has been dribbled in.

The doc said everything about how to set up a rewrite...  except that the vhost is supposed
to point to it (rather than an actual page).
https://wiki.apache.org/couchdb/Rewriting_urls

The earlier post didn't show a [vhosts] where it pointed to the rewrite.

Because "_rewrite" looks like a design rule.  And some design rules are called whether you
want them to be or not, as in "_auth".  The connection is not spelled out.

Its the difference between the big people who wrote it looking down over the whole system,
and the little people trying to learn it looking in and having only disconnected pieces.

Lastly, I am proxy-ing through a server anyway.  To restrict _all_dbs, _utils, etc... from
the public, but allow them locally.  So the front door web server is serving up the root
page, and I can direct inbounds anywhere I want from there.

But now that I learned more about how it works, I will experiment with it in the future.

-Scott



________________________________
 From: Benoit Chesneau <bchesneau@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>; Scott Weber <scotty2541@sbcglobal.net>

Sent: Friday, April 18, 2014 11:40 PM
Subject: Re: authentication_redirect is not working.
 

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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message