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] > 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. I need to send that email to the Lift list asking for help... > [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? Thanks, Ethan
