From user-return-13075-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Oct 06 21:18:54 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 7840 invoked from network); 6 Oct 2010 21:18:53 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Oct 2010 21:18:53 -0000 Received: (qmail 40909 invoked by uid 500); 6 Oct 2010 21:18:52 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 40839 invoked by uid 500); 6 Oct 2010 21:18:51 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 40831 invoked by uid 99); 6 Oct 2010 21:18:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Oct 2010 21:18:51 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of wout.mertens@gmail.com designates 209.85.215.52 as permitted sender) Received: from [209.85.215.52] (HELO mail-ew0-f52.google.com) (209.85.215.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Oct 2010 21:18:42 +0000 Received: by ewy20 with SMTP id 20so10060ewy.11 for ; Wed, 06 Oct 2010 14:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=WamqqHvIk9yQW+QE8STrkDyCmWReX0gSbTUZFGbT1j4=; b=QWoEoyS2958nIqv0ccmT5HQCl1ekEwcfcPmyE3O0HzXvfORZNvV0MMtgh+6oPkmZfd 2D4Oq0dj004M9V6RxeqVvDMKCoYqj4ntNPHxRPzL3XdNq7HQQSa5T6iFZaPq5Sc4LMYF ZeuXUOlG72u5LFcn9rdRrAn9QAZw/QvXnQulQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=ERhB+jJNbLbbi7SqQBi/5P1hjZ7uvcTWnWKV9P/3K8oTjcJyrQYJptE+e7wKDPOsMl +iQDbHzx0owex4HDjgjKWt0ZnWOkhfjWtnbQeeqrow5Zcp4llZ10GS++UcEku73dPf1w hPKQl1ut7OgKNcEDdKvxxa/TDAWVnis1X9AWs= Received: by 10.213.41.133 with SMTP id o5mr1029618ebe.54.1286399902062; Wed, 06 Oct 2010 14:18:22 -0700 (PDT) Received: from [192.168.2.13] (94-224-251-197.access.telenet.be [94.224.251.197]) by mx.google.com with ESMTPS id v59sm2181138eeh.16.2010.10.06.14.18.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 06 Oct 2010 14:18:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: Authentication with Facebook From: Wout Mertens In-Reply-To: Date: Wed, 6 Oct 2010 23:18:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F614453-1888-4E51-B1B1-F917B38D2141@gmail.com> References: To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1081) X-Virus-Checked: Checked by ClamAV on apache.org Hi, I don't know the answer to your question but I think it's interesting so = here's my take on it. You're trying to authorize server-side behavior based on third-party = authentication. I think this only works if you have a way of verifying = that the authentication is valid and couldn't have been forged. I don't see a way of implementing that without custom server-side code = (and probably more information than the OAuth token gives you). You = might be able to do this with = http://wiki.apache.org/couchdb/ExternalProcesses As for your other question, if you're not hiding any data or code on = your server, I think there's nothing you can do to prevent someone from = copying your stuff and running a modified version of it. So to implement what you want, I think that the very least you'll have = to do is run some server-side code and you'll have to hide some data = behind a processing function. For the authentication, you could have something server-side that takes = an OAuth token and contacts Facebook to verify that the token is valid. = Then you know which Facebook user you're talking to. For the data hiding, think about exactly what data users are allowed to = see and provide only access to that (using redirection to views). Other = data will be hidden in the database, inaccessible. Wout. On Oct 5, 2010, at 22:00 , Bernd Mrohs wrote: > Hi all, >=20 > I really like CouchDB for developing pure JS+HTML+CSS applications. = It's > especially great to be able to develop 2-tier applications, i.e. = having all > the logic in JS and accessing CouchDB directly. >=20 > I hope you can help me with a problem on how to secure my CouchDB that = I > want to use for a Facebook project: >=20 > - My pure JS Facebook app authenticates with Facebook using oauth, I = get > back the access token to authenticate my requests to the Facebook API. > - Now my JS application should access my CouchDB backend, using the = UID that > I got from Facebook (logged-in user) >=20 > Question: > - How can I make sure that this user (=3DFacebook UID) can only modify = his own > data? I don't have a password to verify. > - How can I make sure that nobody is implementing an own client by = going > through my JS code, capturing all relevant info (server address, = etc.), and > plays around with the data outside my Facebook app? >=20 > So, I need to let CouchDB verify my Facebook token directly with = Facebook, > and issue an access token for me to send with further requests to my = CouchDB > to authenticate me. This is how you normally would do this when you = would > have a middle-tier, right? How to do this with CouchDB? >=20 > Many thanks in advance, > Bernd