Security refactor
Locked
12
12
 
|
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" <[hidden email]> >>> 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 |
|
|
In reply to this post by Adam Heath-2
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" <[hidden email]> >>>> 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 |
|
|
In reply to this post by David E. Jones-2
--- On Thu, 9/16/10, David E Jones <[hidden email]> 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" <[hidden email]> > >>> 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 |
|
|
In reply to this post by David E. Jones-2
--- On Thu, 9/16/10, David E Jones <[hidden email]> 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" <[hidden email]> > >>>> 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 |
Administrator
|
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" <[hidden email]> > --- On Thu, 9/16/10, David E Jones <[hidden email]> 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" <[hidden email]> >> >>>> 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 > > > > > |
|
|
In reply to this post by David E. Jones-2
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? |
|
|
In reply to this post by Jacques Le Roux
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 |
|
|
In reply to this post by james_sg
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 >>>> >>> >>> >> >> > |
|
|
In reply to this post by Adrian Crum-2
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 <[hidden email]> 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" <[hidden email]> >>>>> 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 > > > > |
|
|
In reply to this post by Adrian Crum-2
On Sep 17, 2010, at 12:50 AM, Adrian Crum wrote: > --- On Thu, 9/16/10, David E Jones <[hidden email]> 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" <[hidden email]> >>>>>> 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 |
|
|
In reply to this post by David E. Jones-2
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 |
|
|
In reply to this post by David E. Jones-2
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. |
|
Administrator
|
In reply to this post by David E. Jones-2
From: "David E Jones" <[hidden email]>
> 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 <[hidden email]> 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" <[hidden email]> >>>>>> 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 >> >> >> >> > |
|
|
In reply to this post by Jacques Le Roux
Hi Jacques,
Something related to authorization.. http://incubator.apache.org/shiro/permissions.html Regards, James
|
|
Administrator
|
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" <[hidden email]> > > 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. > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |