You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2010/09/13 10:40:32 UTC
Security refactor
Hi,
Just curious, what is going on finally with Security refactor?
Jacques
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign ?
Jacques
From: "Hans Bakker" <ma...@antwebsystems.com>
> Can you point to a description how it it should be setup?
>
>
> On Mon, 2010-09-13 at 09:23 -0700, Adrian Crum wrote:
>> Anyone wanting to give the security redesign a try is welcome to do so.
>> The Example component is converted over to the new security design, but
>> the rest of the applications still use the old-style security.
>>
>> One of the goals of the redesign was to have it work along side the
>> old-style security - so OFBiz users can migrate over to the new design
>> when time and resources permit. The notion that the redesign would have
>> a big impact on existing installations isn't true.
>>
>> -Adrian
>>
>> On 9/13/2010 8:33 AM, David E Jones wrote:
>> >
>> > I think we've hit the point where large framework changes like the ExecutionContext and the security redesign have so much of
>> > an impact on higher level code and on large numbers of people in the community that it is unlikely they will be implemented and
>> > pushed out. If they were to be completed there would then be a TON of stuff that could be cleaned up and eliminated from the
>> > framework, which would also be great, but also have a lot of impact on people/organizations and on existing code.
>> >
>> > This is not really likely, and probably not really a good idea. That's why I started a separate project to incorporate many
>> > redesign ideas for the framework (ie Moqui), and it is structured differently to help with certain other difficulties we're
>> > having in OFBiz (ie framework only instead of full stack, fully moderated instead of community-driven, etc). Anyway, I put
>> > together a list a while ago with all of the major differences between Moqui and the OFBiz Framework and that is still easily
>> > available on the Moqui SourceForge site in a forum post. Of course, Moqui is also just a design exercise so far and I haven't
>> > started any implementation (not that I haven't been itching to for a while... ;) ).
>> >
>> > -David
>> >
>> >
>> > On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
>> >
>> >> Hi,
>> >>
>> >> Just curious, what is going on finally with Security refactor?
>> >>
>> >> Jacques
>> >>
>> >
>> >
>
> --
> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> Myself on twitter: http://twitter.com/hansbak
> Antwebsystems.com: Quality services for competitive rates.
>
Re: Security refactor
Posted by Hans Bakker <ma...@antwebsystems.com>.
Can you point to a description how it it should be setup?
On Mon, 2010-09-13 at 09:23 -0700, Adrian Crum wrote:
> Anyone wanting to give the security redesign a try is welcome to do so.
> The Example component is converted over to the new security design, but
> the rest of the applications still use the old-style security.
>
> One of the goals of the redesign was to have it work along side the
> old-style security - so OFBiz users can migrate over to the new design
> when time and resources permit. The notion that the redesign would have
> a big impact on existing installations isn't true.
>
> -Adrian
>
> On 9/13/2010 8:33 AM, David E Jones wrote:
> >
> > I think we've hit the point where large framework changes like the ExecutionContext and the security redesign have so much of an impact on higher level code and on large numbers of people in the community that it is unlikely they will be implemented and pushed out. If they were to be completed there would then be a TON of stuff that could be cleaned up and eliminated from the framework, which would also be great, but also have a lot of impact on people/organizations and on existing code.
> >
> > This is not really likely, and probably not really a good idea. That's why I started a separate project to incorporate many redesign ideas for the framework (ie Moqui), and it is structured differently to help with certain other difficulties we're having in OFBiz (ie framework only instead of full stack, fully moderated instead of community-driven, etc). Anyway, I put together a list a while ago with all of the major differences between Moqui and the OFBiz Framework and that is still easily available on the Moqui SourceForge site in a forum post. Of course, Moqui is also just a design exercise so far and I haven't started any implementation (not that I haven't been itching to for a while... ;) ).
> >
> > -David
> >
> >
> > On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
> >
> >> Hi,
> >>
> >> Just curious, what is going on finally with Security refactor?
> >>
> >> Jacques
> >>
> >
> >
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
Shiro would replace the home-grown Authorization Manager in the security
redesign -
https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign.
Integrating Shiro in the execution context branch should be pretty
straightforward - since it is nearly identical to the authorization manager.
-Adrian
On 9/15/2010 1:09 AM, james_sg wrote:
>
> Anyone look at Apache Shiro for OFBiz? I have used it in one of my project
> and am happy with it. Seems a nice fit for OFBiz.
>
> -james
>
> Adrian Crum wrote:
>>
>> Anyone wanting to give the security redesign a try is welcome to do so.
>> The Example component is converted over to the new security design, but
>> the rest of the applications still use the old-style security.
>>
>> One of the goals of the redesign was to have it work along side the
>> old-style security - so OFBiz users can migrate over to the new design
>> when time and resources permit. The notion that the redesign would have
>> a big impact on existing installations isn't true.
>>
>> -Adrian
>>
>> On 9/13/2010 8:33 AM, David E Jones wrote:
>>>
>>> I think we've hit the point where large framework changes like the
>>> ExecutionContext and the security redesign have so much of an impact on
>>> higher level code and on large numbers of people in the community that it
>>> is unlikely they will be implemented and pushed out. If they were to be
>>> completed there would then be a TON of stuff that could be cleaned up and
>>> eliminated from the framework, which would also be great, but also have a
>>> lot of impact on people/organizations and on existing code.
>>>
>>> This is not really likely, and probably not really a good idea. That's
>>> why I started a separate project to incorporate many redesign ideas for
>>> the framework (ie Moqui), and it is structured differently to help with
>>> certain other difficulties we're having in OFBiz (ie framework only
>>> instead of full stack, fully moderated instead of community-driven, etc).
>>> Anyway, I put together a list a while ago with all of the major
>>> differences between Moqui and the OFBiz Framework and that is still
>>> easily available on the Moqui SourceForge site in a forum post. Of
>>> course, Moqui is also just a design exercise so far and I haven't started
>>> any implementation (not that I haven't been itching to for a while... ;)
>>> ).
>>>
>>> -David
>>>
>>>
>>> On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
>>>
>>>> Hi,
>>>>
>>>> Just curious, what is going on finally with Security refactor?
>>>>
>>>> Jacques
>>>>
>>>
>>>
>>
>>
>
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
Sorry James,
I did not get any chances yet to have a serious look (looks promising IMO).
BTW I see that Shiro is now a TLP...
Thanks for the head ups
Jacques
From: "james_sg" <sn...@hotmail.com>
>
> Hi Jacques,
>
> Something related to authorization..
> http://incubator.apache.org/shiro/permissions.html
>
> Regards,
> James
>
>
> Jacques Le Roux wrote:
>>
>>
>> But finally should we not consider Apache Shiro and get over all this? For
>> now I only read
>> http://www.ibm.com/developerworks/web/library/wa-apacheshiro/ and did not
>> see anything clear about authorization but I think it's
>> worth looking at it...
>>
>> Jacques
>>
>>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2720124.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Security refactor
Posted by james_sg <sn...@hotmail.com>.
Hi Jacques,
Something related to authorization..
http://incubator.apache.org/shiro/permissions.html
Regards,
James
Jacques Le Roux wrote:
>
>
> But finally should we not consider Apache Shiro and get over all this? For
> now I only read
> http://www.ibm.com/developerworks/web/library/wa-apacheshiro/ and did not
> see anything clear about authorization but I think it's
> worth looking at it...
>
> Jacques
>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2720124.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security refactor
Posted by David E Jones <de...@me.com>.
No, we did not agree on the final design and the security stuff in Moqui is VERY different from what you implemented. In fact, I'd go so far to say that they have little in common, though they do share some of the same concepts (externalized references to artifacts, for example).
One major difference, for example, is inheritance of permission determined at run-time based on how artifacts refer to each other instead of where the artifacts are located (which IMO, as I've expressed before, has little use).
-David
On Sep 16, 2010, at 8:36 AM, Adrian Crum wrote:
> This description of events isn't entirely true.
>
> David didn't reject Andrew's design, the community in general felt excluded from the design process. David simply asked that we discuss the design before code was committed.
>
> The security redesign was the outcome of that discussion. As far as I know, David and I agreed on the final design, but interest in it fell off. I ended up being the only person working on it. Since then, David has included the security redesign in his new project.
>
> -Adrian
>
> On 9/16/2010 12:34 AM, Jacques Le Roux wrote:
>> A 1st step would be to show a POC attached to Jira issue; explanation in
>> comment, sufficient snippet of code to understand in patch. When I work
>> on such I try to use the Example component to avoid any bad side
>> effects; ie Example is a kind of sandbox, nobody will jump to your
>> throat if you make a little mistake. Anyway you would not be the 1st
>> responsible, as a commiter would have to review and commit before it get
>> into core.
>>
>> In one word, show us the case.
>>
>> It's also good to know that 1st Andrew (Zeneski) tried something on this
>> (authentication et especially authorization), David "rejected" it, then
>> Adrian and David tried to work together but finally did not agree. So
>> there is still an executioncontext branch but it seems almost dead. I'm
>> maybe not totally right about this, but at least it's how I see it.
>>
>> Thanks
>>
>> Jacques
>>
>> From: "james_sg" <sn...@hotmail.com>
>>> How can i help on this?
>>>
>>> - james
>>>
>>>
>>> Jacques Le Roux wrote:
>>>>
>>>> Looks more like a revolution IMO (ie a branch ;), want to be involved?
>>>>
>>>> Jacques
>>>>
>>>> From: "james_sg" <sn...@hotmail.com>
>>>>> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>> Jacques Le Roux wrote:
>>>>>>
>>>>>> Interesting...
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "james_sg" <sn...@hotmail.com>
>>>>>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>>>>>> project
>>>>>>> and am happy with it. Seems a nice fit for OFBiz.
>>>>>>>
>>>>>>> -james
>>>>>>>
>>>>>>> Adrian Crum wrote:
>>>>>>>>
>>>>>>>> Anyone wanting to give the security redesign a try is welcome to do
>>>>>>>> so.
>>>>>>>> The Example component is converted over to the new security design,
>>>>>>>> but
>>>>>>>> the rest of the applications still use the old-style security.
>>>>>>>>
>>>>>>>> One of the goals of the redesign was to have it work along side the
>>>>>>>> old-style security - so OFBiz users can migrate over to the new
>>>>>>>> design
>>>>>>>> when time and resources permit. The notion that the redesign would
>>>>>>>> have
>>>>>>>> a big impact on existing installations isn't true.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
>>>>>
>>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541484.html
>>>
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
> Please don't attack me Adrian, I didn't attack you. This is entertaining though, isn't it? I especially like how in your message
> full of attacks message you ask for no more of the same. I reread my message below and I don't see any personal attack to you. So,
> where is this "drama" coming from? Am I missing something here? You can misrepresent things all day, but only the less careful
> readers will ever believe you.
>
> I'm pretty sure I've asked this before, but could you please stop using my name to try to add legitimacy to your ideas? Just leave
> me out of it. It's that simple.
>
> If it's a good idea, present it and it will stand on its own. The quality of an idea has nothing to do with the person who
> expresses it or the people who agree with it.
>
> BTW, I don't think it's only you by any means. In general collaboration seems to have mostly broken down in the project. There are
> lots of people still committing to the same code repository, but not many instances any more of people discussing things and
> planning together, or at least soliciting feedback, and then having multiple people work together to implement based on the plans.
> The project in general is still doing fine and it is growing and things are getting fixed, but collaboration isn't here any more.
I don't totally agree. The new lookups are a good example, the jQuery branch is another. We exchanged at the beginning and then
continued/continue to work together
But yes, less community exchanges in general, I agree. On my own I remember the fruitful exchanges we had on GeoLocation, for
instance. Also maybe it because you are less invoved Davis (it's not a reproach, only a fact ;o)
> Any why is this? Is it because of the people involved? Is it because of the way the community is organized? Is it because the
> whole concept of running this type of project (no central control, no agreed on spec to implement to) was flawed from the
> beginning? Is it something else entirely?
I have not enough time to expand on this, but I don't think it's specifically related to people, more the way we are organized and
certainly the scope of the project.
For instance, take the wiki. I had an idea this afternoon. Remember David when you hired Les Austin? Could we not do the same thing
on behalf of the community. This would mean we bring some money in order to hire a Confluence specialist some days to organize
our documentation. There have been ideas on the user lists recently (notably to group spaces as it's now possible to handle
authorization at the page level). I really believe a better documentation would help much the community. For instance the search
(one space would greatly help) and the index in Google are bad (Export is the solution but still problematic as I said)... Of course
we would need to agree on what to do before... The idea behind is to look more professionnal (look at our "concurrents")
Jacques
>
> I don't know...
>
> -David
>
>
> On Sep 17, 2010, at 12:28 AM, Adrian Crum wrote:
>
>> --- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
>>> On Sep 16, 2010, at 12:37 PM, Adrian Crum wrote:
>>>
>>>> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>>>>> From: "Adrian Crum" <ad...@hlmksw.com>
>>>>>> This description of events isn't entirely
>>> true.
>>>>>>
>>>>>> David didn't reject Andrew's design, the
>>> community in general felt
>>>>>> excluded from the design process. David simply
>>> asked that we discuss
>>>>>> the design before code was committed.
>>>>>
>>>>> Yes exactly, thanks for clarifying Adrian, I knew
>>> I had left some points
>>>>> behind
>>>>>
>>>>>> The security redesign was the outcome of that
>>> discussion. As far as I
>>>>>> know, David and I agreed on the final design,
>>> but interest in it fell
>>>>>> off. I ended up being the only person working
>>> on it. Since then, David
>>>>>> has included the security redesign in his new
>>> project.
>>>>>
>>>>> I tought there were some stumbling blocks, notably
>>> when merging your works.
>>>>
>>>> We only disagreed on the workflow. David wanted to
>>> commit all the changes at once and I wanted to commit them a
>>> little at a time.
>>>
>>> I guess you found a way to get me to comment on these
>>> things... just claim to speak for me and then do so
>>> incorrectly.
>>>
>>> There were other disagreements, but I guess they were not
>>> sufficient to be memorable.
>>>
>>> BTW, the ExecutionContext stuff was a more significant
>>> refactoring and cleanup intended to facilitate multi-tenant
>>> features as well as make the runtime context sensitive
>>> security possible. On the cleanup side it would eliminate
>>> the need for the various ThreadLocal variables that exist in
>>> the framework, and would help keep all of the junk out of
>>> the context and parameters Maps (try logging a context now
>>> to see what I mean).
>>
>> I wasn't speaking for you, I was recalling the events as I remember them.
>>
>> I agree we had other disagreements at the time, but they weren't related to the security redesign (from my perspective) so I
>> didn't mention them. The motivation in my reply was to correct some misrepresentations that were made, hopefully without stirring
>> up even more controversy.
>>
>> Based on Jacques comments, and comments I've received from others in personal conversations, I believe the reason interest in the
>> security redesign dropped off was because of all of the drama surrounding the development of it. Even now, when new interest is
>> being expressed in the security redesign, more drama is being thrown into it. That's unfortunate - because the project suffers as
>> a result.
>>
>> The drama comes from you assigning feelings and motivations to me that aren't there. The truth is, I'm not trying to attack you
>> or goad you.
>>
>> In other words, get over yourself. You aren't some prize target that I'm trying to take down.
>>
>> To the rest of the community I ask that you to please restrict the conversation of the security redesign to the design itself.
>> Maybe then we can see some progress.
>>
>> -Adrian
>>
>>
>>
>>
>
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
On 9/17/2010 9:18 AM, David E Jones wrote:
> I'm pretty sure I've asked this before, but could you please stop using my name to try to add legitimacy to your ideas? Just leave me out of it. It's that simple.
Jacques was the one who brought up your name, and it had nothing to do
with "adding legitimacy to my ideas."
I don't even know what "my ideas" would be in this conversation. The
security redesign was the result of a mailing list discussion in which
many people participated.
Like it or not, you have a history with this project. You and others
have been actors in its development. In a discussion of the history of
the project, your name - as well as anyone else involved - will come up.
That's what happened here. If it bothers you, then that's too bad. I'm
not going to rewrite history just so I don't have to use your name.
-Adrian
Re: Security refactor
Posted by Adam Heath <do...@brainfood.com>.
On 09/17/2010 11:18 AM, David E Jones wrote:
> BTW, I don't think it's only you by any means. In general collaboration seems to have mostly broken down in the project. There are lots of people still committing to the same code repository, but not many instances any more of people discussing things and planning together, or at least soliciting feedback, and then having multiple people work together to implement based on the plans. The project in general is still doing fine and it is growing and things are getting fixed, but collaboration isn't here any more.
Are you nuts? I don't see this at all. Every time we have this
conversation come up, you are the one that says collaboration is not
happening. But no one else says this. I certainly don't see it.
Your assessment of the situation is incorrect, and once you've made
this incorrect observation, you draw incorrect conclusions on it as
well, and then get all frustrated. The root cause, however, is the
initial incorrect assessment.
Re: Security refactor
Posted by David E Jones <de...@me.com>.
Please don't attack me Adrian, I didn't attack you. This is entertaining though, isn't it? I especially like how in your message full of attacks message you ask for no more of the same. I reread my message below and I don't see any personal attack to you. So, where is this "drama" coming from? Am I missing something here? You can misrepresent things all day, but only the less careful readers will ever believe you.
I'm pretty sure I've asked this before, but could you please stop using my name to try to add legitimacy to your ideas? Just leave me out of it. It's that simple.
If it's a good idea, present it and it will stand on its own. The quality of an idea has nothing to do with the person who expresses it or the people who agree with it.
BTW, I don't think it's only you by any means. In general collaboration seems to have mostly broken down in the project. There are lots of people still committing to the same code repository, but not many instances any more of people discussing things and planning together, or at least soliciting feedback, and then having multiple people work together to implement based on the plans. The project in general is still doing fine and it is growing and things are getting fixed, but collaboration isn't here any more.
Any why is this? Is it because of the people involved? Is it because of the way the community is organized? Is it because the whole concept of running this type of project (no central control, no agreed on spec to implement to) was flawed from the beginning? Is it something else entirely?
I don't know...
-David
On Sep 17, 2010, at 12:28 AM, Adrian Crum wrote:
> --- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
>> On Sep 16, 2010, at 12:37 PM, Adrian Crum wrote:
>>
>>> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>>>> From: "Adrian Crum" <ad...@hlmksw.com>
>>>>> This description of events isn't entirely
>> true.
>>>>>
>>>>> David didn't reject Andrew's design, the
>> community in general felt
>>>>> excluded from the design process. David simply
>> asked that we discuss
>>>>> the design before code was committed.
>>>>
>>>> Yes exactly, thanks for clarifying Adrian, I knew
>> I had left some points
>>>> behind
>>>>
>>>>> The security redesign was the outcome of that
>> discussion. As far as I
>>>>> know, David and I agreed on the final design,
>> but interest in it fell
>>>>> off. I ended up being the only person working
>> on it. Since then, David
>>>>> has included the security redesign in his new
>> project.
>>>>
>>>> I tought there were some stumbling blocks, notably
>> when merging your works.
>>>
>>> We only disagreed on the workflow. David wanted to
>> commit all the changes at once and I wanted to commit them a
>> little at a time.
>>
>> I guess you found a way to get me to comment on these
>> things... just claim to speak for me and then do so
>> incorrectly.
>>
>> There were other disagreements, but I guess they were not
>> sufficient to be memorable.
>>
>> BTW, the ExecutionContext stuff was a more significant
>> refactoring and cleanup intended to facilitate multi-tenant
>> features as well as make the runtime context sensitive
>> security possible. On the cleanup side it would eliminate
>> the need for the various ThreadLocal variables that exist in
>> the framework, and would help keep all of the junk out of
>> the context and parameters Maps (try logging a context now
>> to see what I mean).
>
> I wasn't speaking for you, I was recalling the events as I remember them.
>
> I agree we had other disagreements at the time, but they weren't related to the security redesign (from my perspective) so I didn't mention them. The motivation in my reply was to correct some misrepresentations that were made, hopefully without stirring up even more controversy.
>
> Based on Jacques comments, and comments I've received from others in personal conversations, I believe the reason interest in the security redesign dropped off was because of all of the drama surrounding the development of it. Even now, when new interest is being expressed in the security redesign, more drama is being thrown into it. That's unfortunate - because the project suffers as a result.
>
> The drama comes from you assigning feelings and motivations to me that aren't there. The truth is, I'm not trying to attack you or goad you.
>
> In other words, get over yourself. You aren't some prize target that I'm trying to take down.
>
> To the rest of the community I ask that you to please restrict the conversation of the security redesign to the design itself. Maybe then we can see some progress.
>
> -Adrian
>
>
>
>
Re: Security refactor
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
> On Sep 16, 2010, at 12:37 PM, Adrian Crum wrote:
>
> > On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
> >> From: "Adrian Crum" <ad...@hlmksw.com>
> >>> This description of events isn't entirely
> true.
> >>>
> >>> David didn't reject Andrew's design, the
> community in general felt
> >>> excluded from the design process. David simply
> asked that we discuss
> >>> the design before code was committed.
> >>
> >> Yes exactly, thanks for clarifying Adrian, I knew
> I had left some points
> >> behind
> >>
> >>> The security redesign was the outcome of that
> discussion. As far as I
> >>> know, David and I agreed on the final design,
> but interest in it fell
> >>> off. I ended up being the only person working
> on it. Since then, David
> >>> has included the security redesign in his new
> project.
> >>
> >> I tought there were some stumbling blocks, notably
> when merging your works.
> >
> > We only disagreed on the workflow. David wanted to
> commit all the changes at once and I wanted to commit them a
> little at a time.
>
> I guess you found a way to get me to comment on these
> things... just claim to speak for me and then do so
> incorrectly.
>
> There were other disagreements, but I guess they were not
> sufficient to be memorable.
>
> BTW, the ExecutionContext stuff was a more significant
> refactoring and cleanup intended to facilitate multi-tenant
> features as well as make the runtime context sensitive
> security possible. On the cleanup side it would eliminate
> the need for the various ThreadLocal variables that exist in
> the framework, and would help keep all of the junk out of
> the context and parameters Maps (try logging a context now
> to see what I mean).
I wasn't speaking for you, I was recalling the events as I remember them.
I agree we had other disagreements at the time, but they weren't related to the security redesign (from my perspective) so I didn't mention them. The motivation in my reply was to correct some misrepresentations that were made, hopefully without stirring up even more controversy.
Based on Jacques comments, and comments I've received from others in personal conversations, I believe the reason interest in the security redesign dropped off was because of all of the drama surrounding the development of it. Even now, when new interest is being expressed in the security redesign, more drama is being thrown into it. That's unfortunate - because the project suffers as a result.
The drama comes from you assigning feelings and motivations to me that aren't there. The truth is, I'm not trying to attack you or goad you.
In other words, get over yourself. You aren't some prize target that I'm trying to take down.
To the rest of the community I ask that you to please restrict the conversation of the security redesign to the design itself. Maybe then we can see some progress.
-Adrian
Re: Security refactor
Posted by David E Jones <de...@me.com>.
On Sep 16, 2010, at 12:37 PM, Adrian Crum wrote:
> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@hlmksw.com>
>>> This description of events isn't entirely true.
>>>
>>> David didn't reject Andrew's design, the community in general felt
>>> excluded from the design process. David simply asked that we discuss
>>> the design before code was committed.
>>
>> Yes exactly, thanks for clarifying Adrian, I knew I had left some points
>> behind
>>
>>> The security redesign was the outcome of that discussion. As far as I
>>> know, David and I agreed on the final design, but interest in it fell
>>> off. I ended up being the only person working on it. Since then, David
>>> has included the security redesign in his new project.
>>
>> I tought there were some stumbling blocks, notably when merging your works.
>
> We only disagreed on the workflow. David wanted to commit all the changes at once and I wanted to commit them a little at a time.
I guess you found a way to get me to comment on these things... just claim to speak for me and then do so incorrectly.
There were other disagreements, but I guess they were not sufficient to be memorable.
BTW, the ExecutionContext stuff was a more significant refactoring and cleanup intended to facilitate multi-tenant features as well as make the runtime context sensitive security possible. On the cleanup side it would eliminate the need for the various ThreadLocal variables that exist in the framework, and would help keep all of the junk out of the context and parameters Maps (try logging a context now to see what I mean).
-David
Re: Security refactor
Posted by Adam Heath <do...@brainfood.com>.
David E Jones wrote:
> On Sep 16, 2010, at 12:40 PM, Adam Heath wrote:
>> Completely brand new code that doesn't touch anything else *at all* can be committed as a single large chunk. But if you need to alter a bunch of other stuff scattered all over, separate commits are better. It makes it easier to verify correctness, and helps in 4 years when you are trying to figure out why something is broken.
>
> I agree, it is WAY better to have hundreds of small commits with questionable code state in between them.
Huh? Questionable code state?
Re: Security refactor
Posted by David E Jones <de...@me.com>.
On Sep 17, 2010, at 12:50 AM, Adrian Crum wrote:
> --- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
>> On Sep 16, 2010, at 12:40 PM, Adam Heath wrote:
>>
>>> On 09/16/2010 01:37 PM, Adrian Crum wrote:
>>>> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>>>>> From: "Adrian Crum" <ad...@hlmksw.com>
>>>>>> This description of events isn't entirely
>> true.
>>>>>>
>>>>>> David didn't reject Andrew's design, the
>> community in general felt
>>>>>> excluded from the design process. David
>> simply asked that we discuss
>>>>>> the design before code was committed.
>>>>>
>>>>> Yes exactly, thanks for clarifying Adrian, I
>> knew I had left some points
>>>>> behind
>>>>>
>>>>>> The security redesign was the outcome of
>> that discussion. As far as I
>>>>>> know, David and I agreed on the final
>> design, but interest in it fell
>>>>>> off. I ended up being the only person
>> working on it. Since then, David
>>>>>> has included the security redesign in his
>> new project.
>>>>>
>>>>> I tought there were some stumbling blocks,
>> notably when merging your
>>>>> works.
>>>>
>>>> We only disagreed on the workflow. David wanted to
>> commit all the
>>>> changes at once and I wanted to commit them a
>> little at a time.
>>>
>>> Completely brand new code that doesn't touch anything
>> else *at all* can be committed as a single large
>> chunk. But if you need to alter a bunch of other stuff
>> scattered all over, separate commits are better. It
>> makes it easier to verify correctness, and helps in 4 years
>> when you are trying to figure out why something is broken.
>>
>> I agree, it is WAY better to have hundreds of small commits
>> with questionable code state in between them.
>>
>> Again though, Adrian misrepresented what I wanted to do,
>> namely implement the ExecutionContext in a branch and once
>> it is complete and the rest of the framework is cleaned up
>> merge that back into the trunk. I suppose you could say the
>> point of the branch was an attempt to collaborate with
>> others, and on that account it worked out beautifully...
>> I've given up entirely on these things in the OFBiz
>> Framework and instead decided a separate project was the
>> only viable way to see it through.
>
> So, should Moqui be renamed to "One Man's Spite"?
>
I suppose one man's spite is another man's way of moving forward and improving things.
-David
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
On 9/17/2010 12:17 AM, Jacques Le Roux wrote:
> Adrian
>
> I learned the word goad from your previous message "The truth is, I'm
> not trying to attack you or goad you." Look like you are reusing it
> again :o)
Good point. My last reply could be considered an attack. My apologies to
David.
-Adrian
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
Adrian
I learned the word goad from your previous message "The truth is, I'm not trying to attack you or goad you." Look like you are
reusing it again :o)
But finally should we not consider Apache Shiro and get over all this? For now I only read
http://www.ibm.com/developerworks/web/library/wa-apacheshiro/ and did not see anything clear about authorization but I think it's
worth looking at it...
Jacques
From: "Adrian Crum" <ad...@yahoo.com>
> --- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
>> On Sep 16, 2010, at 12:40 PM, Adam Heath wrote:
>>
>> > On 09/16/2010 01:37 PM, Adrian Crum wrote:
>> >> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>> >>> From: "Adrian Crum" <ad...@hlmksw.com>
>> >>>> This description of events isn't entirely
>> true.
>> >>>>
>> >>>> David didn't reject Andrew's design, the
>> community in general felt
>> >>>> excluded from the design process. David
>> simply asked that we discuss
>> >>>> the design before code was committed.
>> >>>
>> >>> Yes exactly, thanks for clarifying Adrian, I
>> knew I had left some points
>> >>> behind
>> >>>
>> >>>> The security redesign was the outcome of
>> that discussion. As far as I
>> >>>> know, David and I agreed on the final
>> design, but interest in it fell
>> >>>> off. I ended up being the only person
>> working on it. Since then, David
>> >>>> has included the security redesign in his
>> new project.
>> >>>
>> >>> I tought there were some stumbling blocks,
>> notably when merging your
>> >>> works.
>> >>
>> >> We only disagreed on the workflow. David wanted to
>> commit all the
>> >> changes at once and I wanted to commit them a
>> little at a time.
>> >
>> > Completely brand new code that doesn't touch anything
>> else *at all* can be committed as a single large
>> chunk. But if you need to alter a bunch of other stuff
>> scattered all over, separate commits are better. It
>> makes it easier to verify correctness, and helps in 4 years
>> when you are trying to figure out why something is broken.
>>
>> I agree, it is WAY better to have hundreds of small commits
>> with questionable code state in between them.
>>
>> Again though, Adrian misrepresented what I wanted to do,
>> namely implement the ExecutionContext in a branch and once
>> it is complete and the rest of the framework is cleaned up
>> merge that back into the trunk. I suppose you could say the
>> point of the branch was an attempt to collaborate with
>> others, and on that account it worked out beautifully...
>> I've given up entirely on these things in the OFBiz
>> Framework and instead decided a separate project was the
>> only viable way to see it through.
>
> So, should Moqui be renamed to "One Man's Spite"?
>
> -Adrian
>
>
>
>
>
Re: Security refactor
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Thu, 9/16/10, David E Jones <de...@me.com> wrote:
> On Sep 16, 2010, at 12:40 PM, Adam Heath wrote:
>
> > On 09/16/2010 01:37 PM, Adrian Crum wrote:
> >> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
> >>> From: "Adrian Crum" <ad...@hlmksw.com>
> >>>> This description of events isn't entirely
> true.
> >>>>
> >>>> David didn't reject Andrew's design, the
> community in general felt
> >>>> excluded from the design process. David
> simply asked that we discuss
> >>>> the design before code was committed.
> >>>
> >>> Yes exactly, thanks for clarifying Adrian, I
> knew I had left some points
> >>> behind
> >>>
> >>>> The security redesign was the outcome of
> that discussion. As far as I
> >>>> know, David and I agreed on the final
> design, but interest in it fell
> >>>> off. I ended up being the only person
> working on it. Since then, David
> >>>> has included the security redesign in his
> new project.
> >>>
> >>> I tought there were some stumbling blocks,
> notably when merging your
> >>> works.
> >>
> >> We only disagreed on the workflow. David wanted to
> commit all the
> >> changes at once and I wanted to commit them a
> little at a time.
> >
> > Completely brand new code that doesn't touch anything
> else *at all* can be committed as a single large
> chunk. But if you need to alter a bunch of other stuff
> scattered all over, separate commits are better. It
> makes it easier to verify correctness, and helps in 4 years
> when you are trying to figure out why something is broken.
>
> I agree, it is WAY better to have hundreds of small commits
> with questionable code state in between them.
>
> Again though, Adrian misrepresented what I wanted to do,
> namely implement the ExecutionContext in a branch and once
> it is complete and the rest of the framework is cleaned up
> merge that back into the trunk. I suppose you could say the
> point of the branch was an attempt to collaborate with
> others, and on that account it worked out beautifully...
> I've given up entirely on these things in the OFBiz
> Framework and instead decided a separate project was the
> only viable way to see it through.
So, should Moqui be renamed to "One Man's Spite"?
-Adrian
Re: Security refactor
Posted by David E Jones <de...@me.com>.
On Sep 16, 2010, at 12:40 PM, Adam Heath wrote:
> On 09/16/2010 01:37 PM, Adrian Crum wrote:
>> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <ad...@hlmksw.com>
>>>> This description of events isn't entirely true.
>>>>
>>>> David didn't reject Andrew's design, the community in general felt
>>>> excluded from the design process. David simply asked that we discuss
>>>> the design before code was committed.
>>>
>>> Yes exactly, thanks for clarifying Adrian, I knew I had left some points
>>> behind
>>>
>>>> The security redesign was the outcome of that discussion. As far as I
>>>> know, David and I agreed on the final design, but interest in it fell
>>>> off. I ended up being the only person working on it. Since then, David
>>>> has included the security redesign in his new project.
>>>
>>> I tought there were some stumbling blocks, notably when merging your
>>> works.
>>
>> We only disagreed on the workflow. David wanted to commit all the
>> changes at once and I wanted to commit them a little at a time.
>
> Completely brand new code that doesn't touch anything else *at all* can be committed as a single large chunk. But if you need to alter a bunch of other stuff scattered all over, separate commits are better. It makes it easier to verify correctness, and helps in 4 years when you are trying to figure out why something is broken.
I agree, it is WAY better to have hundreds of small commits with questionable code state in between them.
Again though, Adrian misrepresented what I wanted to do, namely implement the ExecutionContext in a branch and once it is complete and the rest of the framework is cleaned up merge that back into the trunk. I suppose you could say the point of the branch was an attempt to collaborate with others, and on that account it worked out beautifully... I've given up entirely on these things in the OFBiz Framework and instead decided a separate project was the only viable way to see it through.
-David
Re: Security refactor
Posted by Adam Heath <do...@brainfood.com>.
On 09/16/2010 01:37 PM, Adrian Crum wrote:
> On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@hlmksw.com>
>>> This description of events isn't entirely true.
>>>
>>> David didn't reject Andrew's design, the community in general felt
>>> excluded from the design process. David simply asked that we discuss
>>> the design before code was committed.
>>
>> Yes exactly, thanks for clarifying Adrian, I knew I had left some points
>> behind
>>
>>> The security redesign was the outcome of that discussion. As far as I
>>> know, David and I agreed on the final design, but interest in it fell
>>> off. I ended up being the only person working on it. Since then, David
>>> has included the security redesign in his new project.
>>
>> I tought there were some stumbling blocks, notably when merging your
>> works.
>
> We only disagreed on the workflow. David wanted to commit all the
> changes at once and I wanted to commit them a little at a time.
Completely brand new code that doesn't touch anything else *at all*
can be committed as a single large chunk. But if you need to alter a
bunch of other stuff scattered all over, separate commits are better.
It makes it easier to verify correctness, and helps in 4 years when
you are trying to figure out why something is broken.
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
On 9/16/2010 8:18 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@hlmksw.com>
>> This description of events isn't entirely true.
>>
>> David didn't reject Andrew's design, the community in general felt
>> excluded from the design process. David simply asked that we discuss
>> the design before code was committed.
>
> Yes exactly, thanks for clarifying Adrian, I knew I had left some points
> behind
>
>> The security redesign was the outcome of that discussion. As far as I
>> know, David and I agreed on the final design, but interest in it fell
>> off. I ended up being the only person working on it. Since then, David
>> has included the security redesign in his new project.
>
> I tought there were some stumbling blocks, notably when merging your works.
We only disagreed on the workflow. David wanted to commit all the
changes at once and I wanted to commit them a little at a time.
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@hlmksw.com>
> This description of events isn't entirely true.
>
> David didn't reject Andrew's design, the community in general felt
> excluded from the design process. David simply asked that we discuss the
> design before code was committed.
Yes exactly, thanks for clarifying Adrian, I knew I had left some points behind
> The security redesign was the outcome of that discussion. As far as I
> know, David and I agreed on the final design, but interest in it fell
> off. I ended up being the only person working on it. Since then, David
> has included the security redesign in his new project.
I tought there were some stumbling blocks, notably when merging your works.
Jacques
> -Adrian
>
> On 9/16/2010 12:34 AM, Jacques Le Roux wrote:
>> A 1st step would be to show a POC attached to Jira issue; explanation in
>> comment, sufficient snippet of code to understand in patch. When I work
>> on such I try to use the Example component to avoid any bad side
>> effects; ie Example is a kind of sandbox, nobody will jump to your
>> throat if you make a little mistake. Anyway you would not be the 1st
>> responsible, as a commiter would have to review and commit before it get
>> into core.
>>
>> In one word, show us the case.
>>
>> It's also good to know that 1st Andrew (Zeneski) tried something on this
>> (authentication et especially authorization), David "rejected" it, then
>> Adrian and David tried to work together but finally did not agree. So
>> there is still an executioncontext branch but it seems almost dead. I'm
>> maybe not totally right about this, but at least it's how I see it.
>>
>> Thanks
>>
>> Jacques
>>
>> From: "james_sg" <sn...@hotmail.com>
>>> How can i help on this?
>>>
>>> - james
>>>
>>>
>>> Jacques Le Roux wrote:
>>>>
>>>> Looks more like a revolution IMO (ie a branch ;), want to be involved?
>>>>
>>>> Jacques
>>>>
>>>> From: "james_sg" <sn...@hotmail.com>
>>>>> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>> Jacques Le Roux wrote:
>>>>>>
>>>>>> Interesting...
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "james_sg" <sn...@hotmail.com>
>>>>>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>>>>>> project
>>>>>>> and am happy with it. Seems a nice fit for OFBiz.
>>>>>>>
>>>>>>> -james
>>>>>>>
>>>>>>> Adrian Crum wrote:
>>>>>>>>
>>>>>>>> Anyone wanting to give the security redesign a try is welcome to do
>>>>>>>> so.
>>>>>>>> The Example component is converted over to the new security design,
>>>>>>>> but
>>>>>>>> the rest of the applications still use the old-style security.
>>>>>>>>
>>>>>>>> One of the goals of the redesign was to have it work along side the
>>>>>>>> old-style security - so OFBiz users can migrate over to the new
>>>>>>>> design
>>>>>>>> when time and resources permit. The notion that the redesign would
>>>>>>>> have
>>>>>>>> a big impact on existing installations isn't true.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
>>>>>
>>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541484.html
>>>
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
This description of events isn't entirely true.
David didn't reject Andrew's design, the community in general felt
excluded from the design process. David simply asked that we discuss the
design before code was committed.
The security redesign was the outcome of that discussion. As far as I
know, David and I agreed on the final design, but interest in it fell
off. I ended up being the only person working on it. Since then, David
has included the security redesign in his new project.
-Adrian
On 9/16/2010 12:34 AM, Jacques Le Roux wrote:
> A 1st step would be to show a POC attached to Jira issue; explanation in
> comment, sufficient snippet of code to understand in patch. When I work
> on such I try to use the Example component to avoid any bad side
> effects; ie Example is a kind of sandbox, nobody will jump to your
> throat if you make a little mistake. Anyway you would not be the 1st
> responsible, as a commiter would have to review and commit before it get
> into core.
>
> In one word, show us the case.
>
> It's also good to know that 1st Andrew (Zeneski) tried something on this
> (authentication et especially authorization), David "rejected" it, then
> Adrian and David tried to work together but finally did not agree. So
> there is still an executioncontext branch but it seems almost dead. I'm
> maybe not totally right about this, but at least it's how I see it.
>
> Thanks
>
> Jacques
>
> From: "james_sg" <sn...@hotmail.com>
>> How can i help on this?
>>
>> - james
>>
>>
>> Jacques Le Roux wrote:
>>>
>>> Looks more like a revolution IMO (ie a branch ;), want to be involved?
>>>
>>> Jacques
>>>
>>> From: "james_sg" <sn...@hotmail.com>
>>>> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>>>>
>>>> James
>>>>
>>>>
>>>> Jacques Le Roux wrote:
>>>>>
>>>>> Interesting...
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "james_sg" <sn...@hotmail.com>
>>>>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>>>>> project
>>>>>> and am happy with it. Seems a nice fit for OFBiz.
>>>>>>
>>>>>> -james
>>>>>>
>>>>>> Adrian Crum wrote:
>>>>>>>
>>>>>>> Anyone wanting to give the security redesign a try is welcome to do
>>>>>>> so.
>>>>>>> The Example component is converted over to the new security design,
>>>>>>> but
>>>>>>> the rest of the applications still use the old-style security.
>>>>>>>
>>>>>>> One of the goals of the redesign was to have it work along side the
>>>>>>> old-style security - so OFBiz users can migrate over to the new
>>>>>>> design
>>>>>>> when time and resources permit. The notion that the redesign would
>>>>>>> have
>>>>>>> a big impact on existing installations isn't true.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
>>>>
>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541484.html
>>
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>
>
>
Re: Security refactor
Posted by james_sg <sn...@hotmail.com>.
Thanks for the explanation. Will probably look into this next month.
-james
Jacques Le Roux wrote:
>
> A 1st step would be to show a POC attached to Jira issue; explanation in
> comment, sufficient snippet of code to understand in patch.
> When I work on such I try to use the Example component to avoid any bad
> side effects; ie Example is a kind of sandbox, nobody will
> jump to your throat if you make a little mistake. Anyway you would not be
> the 1st responsible, as a commiter would have to review
> and commit before it get into core.
>
> In one word, show us the case.
>
> It's also good to know that 1st Andrew (Zeneski) tried something on this
> (authentication et especially authorization), David
> "rejected" it, then Adrian and David tried to work together but finally
> did not agree. So there is still an executioncontext branch
> but it seems almost dead. I'm maybe not totally right about this, but at
> least it's how I see it.
>
> Thanks
>
> Jacques
>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541915.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
A 1st step would be to show a POC attached to Jira issue; explanation in comment, sufficient snippet of code to understand in patch.
When I work on such I try to use the Example component to avoid any bad side effects; ie Example is a kind of sandbox, nobody will
jump to your throat if you make a little mistake. Anyway you would not be the 1st responsible, as a commiter would have to review
and commit before it get into core.
In one word, show us the case.
It's also good to know that 1st Andrew (Zeneski) tried something on this (authentication et especially authorization), David
"rejected" it, then Adrian and David tried to work together but finally did not agree. So there is still an executioncontext branch
but it seems almost dead. I'm maybe not totally right about this, but at least it's how I see it.
Thanks
Jacques
From: "james_sg" <sn...@hotmail.com>
> How can i help on this?
>
> - james
>
>
> Jacques Le Roux wrote:
>>
>> Looks more like a revolution IMO (ie a branch ;), want to be involved?
>>
>> Jacques
>>
>> From: "james_sg" <sn...@hotmail.com>
>>> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>>>
>>> James
>>>
>>>
>>> Jacques Le Roux wrote:
>>>>
>>>> Interesting...
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>> From: "james_sg" <sn...@hotmail.com>
>>>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>>>> project
>>>>> and am happy with it. Seems a nice fit for OFBiz.
>>>>>
>>>>> -james
>>>>>
>>>>> Adrian Crum wrote:
>>>>>>
>>>>>> Anyone wanting to give the security redesign a try is welcome to do
>>>>>> so.
>>>>>> The Example component is converted over to the new security design,
>>>>>> but
>>>>>> the rest of the applications still use the old-style security.
>>>>>>
>>>>>> One of the goals of the redesign was to have it work along side the
>>>>>> old-style security - so OFBiz users can migrate over to the new design
>>>>>> when time and resources permit. The notion that the redesign would
>>>>>> have
>>>>>> a big impact on existing installations isn't true.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541484.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Security refactor
Posted by james_sg <sn...@hotmail.com>.
How can i help on this?
- james
Jacques Le Roux wrote:
>
> Looks more like a revolution IMO (ie a branch ;), want to be involved?
>
> Jacques
>
> From: "james_sg" <sn...@hotmail.com>
>> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>>
>> James
>>
>>
>> Jacques Le Roux wrote:
>>>
>>> Interesting...
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> From: "james_sg" <sn...@hotmail.com>
>>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>>> project
>>>> and am happy with it. Seems a nice fit for OFBiz.
>>>>
>>>> -james
>>>>
>>>> Adrian Crum wrote:
>>>>>
>>>>> Anyone wanting to give the security redesign a try is welcome to do
>>>>> so.
>>>>> The Example component is converted over to the new security design,
>>>>> but
>>>>> the rest of the applications still use the old-style security.
>>>>>
>>>>> One of the goals of the redesign was to have it work along side the
>>>>> old-style security - so OFBiz users can migrate over to the new design
>>>>> when time and resources permit. The notion that the redesign would
>>>>> have
>>>>> a big impact on existing installations isn't true.
>>>>>
>>>>> -Adrian
>>>>>
>>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2541484.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
Looks more like a revolution IMO (ie a branch ;), want to be involved?
Jacques
From: "james_sg" <sn...@hotmail.com>
> Thanks for looking. Moving to Apache Shiro should be an evolution ....
>
> James
>
>
> Jacques Le Roux wrote:
>>
>> Interesting...
>>
>> Thanks
>>
>> Jacques
>>
>> From: "james_sg" <sn...@hotmail.com>
>>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>>> project
>>> and am happy with it. Seems a nice fit for OFBiz.
>>>
>>> -james
>>>
>>> Adrian Crum wrote:
>>>>
>>>> Anyone wanting to give the security redesign a try is welcome to do so.
>>>> The Example component is converted over to the new security design, but
>>>> the rest of the applications still use the old-style security.
>>>>
>>>> One of the goals of the redesign was to have it work along side the
>>>> old-style security - so OFBiz users can migrate over to the new design
>>>> when time and resources permit. The notion that the redesign would have
>>>> a big impact on existing installations isn't true.
>>>>
>>>> -Adrian
>>>>
>>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Security refactor
Posted by james_sg <sn...@hotmail.com>.
Thanks for looking. Moving to Apache Shiro should be an evolution ....
James
Jacques Le Roux wrote:
>
> Interesting...
>
> Thanks
>
> Jacques
>
> From: "james_sg" <sn...@hotmail.com>
>> Anyone look at Apache Shiro for OFBiz? I have used it in one of my
>> project
>> and am happy with it. Seems a nice fit for OFBiz.
>>
>> -james
>>
>> Adrian Crum wrote:
>>>
>>> Anyone wanting to give the security redesign a try is welcome to do so.
>>> The Example component is converted over to the new security design, but
>>> the rest of the applications still use the old-style security.
>>>
>>> One of the goals of the redesign was to have it work along side the
>>> old-style security - so OFBiz users can migrate over to the new design
>>> when time and resources permit. The notion that the redesign would have
>>> a big impact on existing installations isn't true.
>>>
>>> -Adrian
>>>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540207.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
Interesting...
Thanks
Jacques
From: "james_sg" <sn...@hotmail.com>
> Anyone look at Apache Shiro for OFBiz? I have used it in one of my project
> and am happy with it. Seems a nice fit for OFBiz.
>
> -james
>
> Adrian Crum wrote:
>>
>> Anyone wanting to give the security redesign a try is welcome to do so.
>> The Example component is converted over to the new security design, but
>> the rest of the applications still use the old-style security.
>>
>> One of the goals of the redesign was to have it work along side the
>> old-style security - so OFBiz users can migrate over to the new design
>> when time and resources permit. The notion that the redesign would have
>> a big impact on existing installations isn't true.
>>
>> -Adrian
>>
>> On 9/13/2010 8:33 AM, David E Jones wrote:
>>>
>>> I think we've hit the point where large framework changes like the
>>> ExecutionContext and the security redesign have so much of an impact on
>>> higher level code and on large numbers of people in the community that it
>>> is unlikely they will be implemented and pushed out. If they were to be
>>> completed there would then be a TON of stuff that could be cleaned up and
>>> eliminated from the framework, which would also be great, but also have a
>>> lot of impact on people/organizations and on existing code.
>>>
>>> This is not really likely, and probably not really a good idea. That's
>>> why I started a separate project to incorporate many redesign ideas for
>>> the framework (ie Moqui), and it is structured differently to help with
>>> certain other difficulties we're having in OFBiz (ie framework only
>>> instead of full stack, fully moderated instead of community-driven, etc).
>>> Anyway, I put together a list a while ago with all of the major
>>> differences between Moqui and the OFBiz Framework and that is still
>>> easily available on the Moqui SourceForge site in a forum post. Of
>>> course, Moqui is also just a design exercise so far and I haven't started
>>> any implementation (not that I haven't been itching to for a while... ;)
>>> ).
>>>
>>> -David
>>>
>>>
>>> On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
>>>
>>>> Hi,
>>>>
>>>> Just curious, what is going on finally with Security refactor?
>>>>
>>>> Jacques
>>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540080.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: Security refactor
Posted by james_sg <sn...@hotmail.com>.
Anyone look at Apache Shiro for OFBiz? I have used it in one of my project
and am happy with it. Seems a nice fit for OFBiz.
-james
Adrian Crum wrote:
>
> Anyone wanting to give the security redesign a try is welcome to do so.
> The Example component is converted over to the new security design, but
> the rest of the applications still use the old-style security.
>
> One of the goals of the redesign was to have it work along side the
> old-style security - so OFBiz users can migrate over to the new design
> when time and resources permit. The notion that the redesign would have
> a big impact on existing installations isn't true.
>
> -Adrian
>
> On 9/13/2010 8:33 AM, David E Jones wrote:
>>
>> I think we've hit the point where large framework changes like the
>> ExecutionContext and the security redesign have so much of an impact on
>> higher level code and on large numbers of people in the community that it
>> is unlikely they will be implemented and pushed out. If they were to be
>> completed there would then be a TON of stuff that could be cleaned up and
>> eliminated from the framework, which would also be great, but also have a
>> lot of impact on people/organizations and on existing code.
>>
>> This is not really likely, and probably not really a good idea. That's
>> why I started a separate project to incorporate many redesign ideas for
>> the framework (ie Moqui), and it is structured differently to help with
>> certain other difficulties we're having in OFBiz (ie framework only
>> instead of full stack, fully moderated instead of community-driven, etc).
>> Anyway, I put together a list a while ago with all of the major
>> differences between Moqui and the OFBiz Framework and that is still
>> easily available on the Moqui SourceForge site in a forum post. Of
>> course, Moqui is also just a design exercise so far and I haven't started
>> any implementation (not that I haven't been itching to for a while... ;)
>> ).
>>
>> -David
>>
>>
>> On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> Just curious, what is going on finally with Security refactor?
>>>
>>> Jacques
>>>
>>
>>
>
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Security-refactor-tp2537069p2540080.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
Anyone wanting to give the security redesign a try is welcome to do so.
The Example component is converted over to the new security design, but
the rest of the applications still use the old-style security.
One of the goals of the redesign was to have it work along side the
old-style security - so OFBiz users can migrate over to the new design
when time and resources permit. The notion that the redesign would have
a big impact on existing installations isn't true.
-Adrian
On 9/13/2010 8:33 AM, David E Jones wrote:
>
> I think we've hit the point where large framework changes like the ExecutionContext and the security redesign have so much of an impact on higher level code and on large numbers of people in the community that it is unlikely they will be implemented and pushed out. If they were to be completed there would then be a TON of stuff that could be cleaned up and eliminated from the framework, which would also be great, but also have a lot of impact on people/organizations and on existing code.
>
> This is not really likely, and probably not really a good idea. That's why I started a separate project to incorporate many redesign ideas for the framework (ie Moqui), and it is structured differently to help with certain other difficulties we're having in OFBiz (ie framework only instead of full stack, fully moderated instead of community-driven, etc). Anyway, I put together a list a while ago with all of the major differences between Moqui and the OFBiz Framework and that is still easily available on the Moqui SourceForge site in a forum post. Of course, Moqui is also just a design exercise so far and I haven't started any implementation (not that I haven't been itching to for a while... ;) ).
>
> -David
>
>
> On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> Just curious, what is going on finally with Security refactor?
>>
>> Jacques
>>
>
>
Re: Security refactor
Posted by David E Jones <de...@me.com>.
I think we've hit the point where large framework changes like the ExecutionContext and the security redesign have so much of an impact on higher level code and on large numbers of people in the community that it is unlikely they will be implemented and pushed out. If they were to be completed there would then be a TON of stuff that could be cleaned up and eliminated from the framework, which would also be great, but also have a lot of impact on people/organizations and on existing code.
This is not really likely, and probably not really a good idea. That's why I started a separate project to incorporate many redesign ideas for the framework (ie Moqui), and it is structured differently to help with certain other difficulties we're having in OFBiz (ie framework only instead of full stack, fully moderated instead of community-driven, etc). Anyway, I put together a list a while ago with all of the major differences between Moqui and the OFBiz Framework and that is still easily available on the Moqui SourceForge site in a forum post. Of course, Moqui is also just a design exercise so far and I haven't started any implementation (not that I haven't been itching to for a while... ;) ).
-David
On Sep 13, 2010, at 2:40 AM, Jacques Le Roux wrote:
> Hi,
>
> Just curious, what is going on finally with Security refactor?
>
> Jacques
>
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
RIP :o)
Jacques
From: "Adrian Crum" <ad...@hlmksw.com>
> Nothing is going on with it right now. There was little interest in it,
> so it died.
>
> -Adrian
>
> On 9/13/2010 1:40 AM, Jacques Le Roux wrote:
>> Hi,
>>
>> Just curious, what is going on finally with Security refactor?
>>
>> Jacques
>>
>>
>
Re: Security refactor
Posted by Adrian Crum <ad...@hlmksw.com>.
Nothing is going on with it right now. There was little interest in it,
so it died.
-Adrian
On 9/13/2010 1:40 AM, Jacques Le Roux wrote:
> Hi,
>
> Just curious, what is going on finally with Security refactor?
>
> Jacques
>
>
Re: Security refactor
Posted by Jacques Le Roux <ja...@les7arts.com>.
BTW I have just learned today that Security refactor is a revolution:
http://incubator.apache.org/learn/rules-for-revolutionaries.html :o) The standard mode is called evolution
http://www.apache.org/foundation/glossary.html#Evolution
jQuery branch is as well. As it's less controversed, I guess it will be merged back sooner or later, will executioncontext have a
chance?
BTW it's related to http://dashes.com/anil/2010/09/forking-is-a-feature.html and for those not aware but still interested there is
currently a discussion (subject: "Forking is a Feature" reactions?) in community@apache.org ML (it's open to everyone)
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> Hi,
>
> Just curious, what is going on finally with Security refactor?
>
> Jacques
>