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: domain of florian.leitner@gmail.com
 designates 209.85.214.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=h6ZYSpRG14pon0fA3Ib/xZhCKZB3Zp4BgVdqM5tVyo0qtT4yC1NNPRlJW5Bxy8Y/U+
         3c5p8f4J4kCf+59qlp0Y8rs59wWBHCD+M0w6rpH+lkm1izMRomL0Cje9C5TiQ6WGm3fB
         nCh18t/TjhCWfZqXCHcqXAkPQLHPLczqfQe9w=
MIME-Version: 1.0
In-Reply-To: <BF899C04-BB48-487D-B975-B2BAC193F2B8@vpro.nl>
References: <AANLkTinSUxFo6cX=uH+55XjgnwignxBbhM1hoUixARWY@mail.gmail.com>
 <BF899C04-BB48-487D-B975-B2BAC193F2B8@vpro.nl>
From: Florian Leitner <florian.leitner@gmail.com>
Date: Fri, 10 Dec 2010 16:45:46 +0100
Message-ID: <AANLkTimE5LMfpBKitnCd9fN7NNkj7=wRr5OJEOGfpz6x@mail.gmail.com>
Subject: Re: CouchDB/App, XHR, and the JavaScript Same Origin Policy
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nils,

Thanks for your suggestion! However, I am completely aware of the fact
that you can do replication and synchronization in CouchDB. Maybe I
did not explain myself sufficiently: What I need to do is find a way
to make CORS (Cross-Origin Resource Sharing) requests to websites that
do not actually implement CORS (i.e., provide the CORS headers you
have to add to your server responses) via an application that uses
CouchDB as its permanent storage. By "coincidence", those requests
could be sent to sites could even be sites running CouchDB and even my
application, but that do not actually share any data. The only way to
do that seems to use some "man-in-the-middle" webserver solution, or
if CouchDB would provide some means to create a XHR (XmlHttpRequest)
proxy, so you can work around that Single Origin Policy problem.

So, if it were a "man-in-the-middle" solution by adding a web server
(which seems the only way to go so far), it should be as flexible as
CouchDB and at the very least run on all three main desktop platfoms:
Linux, Apple, and Windoze. The current solutions I have found so far
not really work out: LivelyCouch & node.js does not work on Windoze
(bummer, but I can understand the guys...). XULRunner/XULjet only
works for desktop apps, so I realized it doesn't really solve my issue
either, because you would have to create two interfaces: one for the
server part based - for example - via LivelyCouch, and one for
XULRunner/XULjet to make a desktop app that can run on many different
platforms. This is the closest I currently got to a solution, but it
isn't optimal, because I will have to maintain two interface
libraries...

Regards,
Florian

On 10 December 2010 10:51, Nils Breunese <N.Breunese@vpro.nl> wrote:
> I think it's more CouchApp-y to not think about separate server and clien=
t applications, but just putting the app on the user's local CouchDB. You'd=
 use CouchDB replication to synchronize the big master CouchDB and the user=
's local instance. That way you'll never run into things like same origin p=
olicy restrictions, etc.
>
> Nils.
>
> Op 10 dec 2010, om 02:05 heeft Florian Leitner het volgende geschreven:
>
>> Hi everybody,
>>
>> I want to develop an app that essentially could run "out of CouchDB"
>> itself, much like you can do via CouchApp. There will be two version
>> of that app, one can be imagined as a "server", holding a huge
>> (Couch)DB somewhere, the other as "client", which is locally installed
>> by users and only holds the data they are interested in, inside their
>> own local (Couch)DB. The interface to that client-CouchDB I would
>> directly build using CouchApp. So far, this, I understand, should be
>> exactly what you can do with CouchDB/App. Now here is the issue I
>> have:
>>
>> First I want users to be able to POST to the server-CouchDB while
>> browsing their client-CouchDB/App; That means, imagine you installed
>> my client app with CouchDB, you will be looking at documents on
>> localhost:5984/some_db. Now the user should be able to POST a document
>> to the "server" that is on the domain "example.com:5984/another_db".
>> Technically, this is made very tough because off the Same Domain
>> Origin Policy if this POST were done via JavaScript XHR directly from
>> the user's browser. Furthermore, the app I am working on should also
>> allow them to gather data from other sites, and users will be able to
>> download and store data from those other websites into their CouchDB,
>> too - such as, let's say, adding a XML document from another server,
>> say "example2.com/xml_rest_resource", to their "client" CouchDB.
>> Again, doing this directly from the user's browser is prohibitive,
>> because he is on "localhost:5984", while I want to GET from (and maybe
>> even POST to) "example2.com".
>>
>> The only other option I see is dropping the whole CouchApp thing and
>> creating a man-in-the-middle web server for the "client" part of my
>> app that communicates with the user's browser and with his local
>> CouchDB. But this is much like you put Rails or Django in between your
>> DB and the browser, and feels verrry Unrelaxing... Yet, this
>> "middleman" then can communicate with other webpages, post to other
>> CouchDBs, etc, because it isn't locked down by this same origin policy
>> stuff.
>>
>> However, if there were a way to create some sort of a XHR proxy
>> "inside" CouchDB, all these issues would go away, too, because the
>> users' browser would always only communicate with the "client"
>> CouchDB, and it would then forward the XHR to other CouchDBs or other
>> websites. Is this possible to do using CouchDB _only_ or do I really
>> have to create a separate "web server" outside of CouchDB? Or am I
>> completely missing something, anyways? I would really love to run this
>> entire thing based on CouchDB only, because it allows you to use an
>> existing CouchDB you have installed and makes updating/installing the
>> application very simple via CouchDB's synchronization/replication
>> capabilities.
>>
>> Thanks for any input, thoughts, or stratagems!
>> Florian
>
> ------------------------------------------------------------------------
> =C2=A0VPRO
> =C2=A0phone: =C2=A0+31(0)356712911
> =C2=A0e-mail: info@vpro.nl
> =C2=A0web: =C2=A0 =C2=A0www.vpro.nl
> ------------------------------------------------------------------------
>