incubator-esme-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Big (first) commit
Date Thu, 31 Dec 2009 23:47:58 GMT
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

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message