Mailing-List: contact esme-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of esjewett@gmail.com designates
 209.85.222.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=YAyVbwJp5SVk5AwWdjuVhMFVkGndGif0rzQQk0MMfUqpfgzLdmnQm5t2Iok0P1AfB1
         BhoFcUc6sznqDBZKqf/RZxUZ5zPs68YX4EP/7i2xAYx0PyR4La1UMOwolEHItm9kQBzp
         f4NeU6pgAuz8w+vOzX+Pq0QqxDfaF+pCOZ2iU=
MIME-Version: 1.0
Date: Thu, 31 Dec 2009 17:47:58 -0600
Message-ID: <68f4a0e80912311547i6ad05615x2ee0273c51dbc9d9@mail.gmail.com>
Subject: Big (first) commit
From: Ethan Jewett <esjewett@gmail.com>
To: esme-commits@incubator.apache.org
Content-Type: multipart/mixed; boundary=001636b2b1727fede3047c0ee296

--001636b2b1727fede3047c0ee296
Content-Type: text/plain; charset=ISO-8859-1

This is kind of making me cringe, but I have several modifications
that I now am having great difficulty sorting out from each other, so
for my first commit I'm doing a no-no and going with one really big
commit. Now that I can create branches and get commits in more easily,
this shouldn't happen again.

In the latest commit (diff attached), there are mostly new and
improved tests for the API2 endpoint, as well as the addition of
several administration/integration-oriented methods requested by Sig &
team (with tests!). However, there are a few things I think everyone
should look at:

1. I've added two things to the User object in the User.scala file: A
new private object "currentRole", and a new method "checkRole". I'm
using these for the role-based authorization on the new API methods
(see below).

2. Role-based authorization checks in API2.scala (see "def authorizationRules")

3. Adding the role-based authorization checks to the
LiftRules.dispatch table *before* the API2 methods (see
"LiftRules.dispatch.append(API2.authorizationRules)")

The way these roles work is that you assign the role to a user in a
.props file. test.default.props is an example that is used in the unit
tests of the new API methods and the authorization wrapped around
them. In a production system you would need to use
production.default.props

Eventually we should make this use the Lift AuthRole in some manner,
if only because of the hierarchical structure it supports. We could
also just create our own role system, but I don't know if I want to be
responsible for that. I'm not currently using Lift roles because of
some issues I outlined on the main esme-dev list.

Ok, that's probably enough about this particular commit. These will be
much shorter in the future also :-)

Also, is there any particular commit message format we're supposed to use?

Happy New Year everyone,
Ethan

--001636b2b1727fede3047c0ee296--