Strange that your commit was registered on this list.... Other comments inline
On Fri, Jan 1, 2010 at 12:47 AM, Ethan Jewett <[email protected]> wrote: > 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: This is good, because it means that Sig might be able to return to the official subversion version rather than his own hacked version. > > 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. I think this is fine for now but we don't want to recreate the lift authorization functionality. Is there a migration path possible? > > 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? [ESME-xxx] JIRA title Extra text xxx = number from Jira JIRA title = Jira title Extra text is optional and says whether it is a patch, etc. > > Happy New Year everyone, > Ethan >
