incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Big (first) commit
Date Fri, 01 Jan 2010 16:45:46 GMT
Ahhhh, ok. I did an svn commit separately, but thought I had to
manually email the esme-commits@incubator.apache.org list to notify
everyone that I'd made the commit. Doh.

Ethan

On Fri, Jan 1, 2010 at 10:29 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
> Comments inline.
>
> On Fri, Jan 1, 2010 at 5:16 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>> On Fri, Jan 1, 2010 at 2:10 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>>> Strange that your commit was registered on this list....
>>
>> That is odd. I sent it to esme-commits@incubator.apache.org
>
> 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
>>
>

Mime
View raw message