From user-return-21009-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon May 28 21:26:37 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D134F9E61 for ; Mon, 28 May 2012 21:26:37 +0000 (UTC) Received: (qmail 67842 invoked by uid 500); 28 May 2012 21:26:36 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 67783 invoked by uid 500); 28 May 2012 21:26:36 -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 67767 invoked by uid 99); 28 May 2012 21:26:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 May 2012 21:26:36 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lmatteis@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 May 2012 21:26:29 +0000 Received: by eeke53 with SMTP id e53so932739eek.11 for ; Mon, 28 May 2012 14:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RWKu98Wbm28kPtjx+/j5frmQ0JuqgvzGklrtPj+UiSo=; b=Iaa7VtuDI4a9iCptnnkt2shzVDnIOLsZsSQIIiSviV9WG+9BungdLuwE1QAGMArR+y BrFshUSR3NQOBx52eqKXr2KiDGdY4SDs8tHoiqeh3p/KGXDcThaOCbqOBLvcOQGYXLwm zmPIyttVq5hZbKP0Uk4KTbyR+kHtJJWP+utTpp9ixntVcii2eeqhV3mhvAUp3tLfIC2j pLrckJJqmwuKHvXdd4UmM5eZ3fLIt9wYL0zD3qDqNs0+qnz+tUjHcjImKSYYdu2CslJp atexNmYFBxOZodd5ZNa0RjjvnwTHmZHJgvO/GGGGxn2zFeGvsYvfFJtgsQFbMTnRRC1n K5OQ== MIME-Version: 1.0 Received: by 10.14.22.12 with SMTP id s12mr2644267ees.213.1338240369324; Mon, 28 May 2012 14:26:09 -0700 (PDT) Received: by 10.14.190.196 with HTTP; Mon, 28 May 2012 14:26:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 May 2012 23:26:09 +0200 Message-ID: Subject: Re: Request object in validate_doc_update From: Luca Matteis To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Yes, I already use update handlers for the voting, but as you said, someone could easily bypass it by directly updating the document. I mean, validate_doc_update's already contain logic that restrict certain actions based on the userCtx (which is some information contained in the request), so why not give the IP address of the request as well? This would allow the creation of even more powerful Couchapps. On Mon, May 28, 2012 at 5:46 PM, Robert Newson wrote: > You can achieve this with an update handler > (http://wiki.apache.org/couchdb/Document_Update_Handlers) but it could > be bypassed by a savvy user. I don't see why a validate_doc_update > function couldn't enforce this it if had access to the req object. I'm > +1. > > B. > > On 28 May 2012 16:06, Luca Matteis wrote: >> Sure. For example I'm allowing my users to vote on certain "items" in >> my database. This will allow me to understand the amount of >> satisfaction of these items. I can easily validate and make sure each >> user is commenting only once, however, someone might simply create a >> new account and re-vote for that item. This defeats the purpose of the >> voting system. >> My solution would be to check based on the IP of the voter, no matter >> what user they're logged in with. >> >> Does this make sense? Thanks. >> >> On Mon, May 28, 2012 at 3:50 PM, Robert Newson wrote: >>> I fear I've derailed this thread, so let's shelve the admin@127.0.0.1 >>> idea for another time and thread. >>> >>> To address the original question; >>> >>> "I have a scenario where I'm building a CouchApp that needs to deny >>> certain behavior from happening based on the user's IP address. >>> Would it be good to consider this as a new feature to be implemented?" >>> >>> Being able to build richer applications within the 2-tier couchapp >>> model is a project goal so I'm generally for the proposal to expose >>> the req object in VDU (since you can access it in show and list and it >>> seems to break nothing). I suspect the full feature set required for >>> your application to not require a proxy or firewall has not been >>> spelled out in detail and, I further suspect, some of it will be >>> better done with a firewall. >>> >>> Could you expand on the 'certain behavior' that should be restricted >>> based on IP? A few examples would help. >>> >>> B. >>> >>> On 28 May 2012 14:38, Simon Metson wrote: >>>> Hi, >>>> >>>> >>>> On Monday, 28 May 2012 at 14:12, Robert Newson wrote: >>>> >>>>> The other proposal might be to allow the granting of >>>>> rights by IP address, much as MySQL does. In fact, I believe this idea >>>>> is part of the Summit proposal to enhance our security model. I should >>>>> be able to grant _admin rights to a user if and only if they come from >>>>> 127.0.0.1, for example. >>>> >>>> We wrote something like this for our deployment at CERN. I thought it had been contributed back to the trunk, but maybe it got lost along the way. I'll see if I can find out the status of it. >>>> Cheers >>>> Simon