Ahhhh, ok. I did an svn commit separately, but thought I had to manually email the [email protected] list to notify everyone that I'd made the commit. Doh.
Ethan On Fri, Jan 1, 2010 at 10:29 AM, Richard Hirsch <[email protected]> wrote: > Comments inline. > > On Fri, Jan 1, 2010 at 5:16 PM, Ethan Jewett <[email protected]> wrote: >> On Fri, Jan 1, 2010 at 2:10 AM, Richard Hirsch <[email protected]> wrote: >>> Strange that your commit was registered on this list.... >> >> That is odd. I sent it to [email protected] > > The commits are sent to the esme-comits mailing list automatically. > Here are the archives of this list: > http://mail-archives.apache.org/mod_mbox/incubator-esme-commits/200912.mbox/browser > > Strange. Your commits made it in: > http://svn.apache.org/viewvc/incubator/esme/trunk/server/ > >> >>> I think this is fine for now but we don't want to recreate the lift >>> authorization functionality. Is there a migration path possible? >> >> The migration path would be to just switch the mechanism over to Lift >> authorizations. However, those don't appear to be suitable. To quote >> myself: >> >> 1. The Lift httpAuthProtectedResource method that all the examples use >> to tie roles to actions in the application is not suitable for a >> RESTful API approach, since it ties authorization to the resource >> rather than the resource/method combination (translation: you can't >> have a resource with different authorization roles for read and >> write, and we need this, at least for the api2/users resource). >> >> 2. Using LiftRules.httpAuthProtectedResource seems to require the use >> of LiftRules.authentication to authenticate requests. [That is, I >> don't see a way to do authorization based on the current user as >> derived from the session.] Unfortunately it >> looks like you can only define one authentication method per >> application (I may be missing something here), and since the Twitter >> API is already using Basic authentication, we can't use a different >> method for the administration API parts of API2. >> > > OK. I understand - the lift functionality appears to be closely linked > to the UI which really isn't useful for our requirements. > >> I need to send that email to the Lift list asking for help... > > Would be useful to make them aware of the problems as well > >> >>> [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. >> >> Thanks, I'll do that in the future. Does that format result in the >> Jira comment posting from Hudson automagically? >> > > Yep. > >> Thanks, >> Ethan >> >
