Bump - looks like we let this get away from us as a discussion. We can all
agree that the current security system that is in place has some definite areas
for improvement - and I think we're getting some where with this discussion -
but I don't want it to lose steam in the community since
.
-Adrian
--- On Sun, 5/10/09, Tim Ruppert tim.rupp...@hotwaxmedia.com wrote:
From: Tim Ruppert tim.rupp...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Sunday, May 10, 2009, 1:19 PM
Bump - looks like we let this get away
- Adam Heath wrote:
Adam Heath wrote:
Have you considered doing a git or mercurial branch of all these changes?
hg clone http://hg.webslinger.org/hg/ofbiz.apache.org/
This situation underscores a discussion that David and I were having about
distributed development. Andy's changes
I step back to this because I believe this is a good point.
Andy:
I did not become aware of your new security till last thur. I have been
wrapped up in other projects and have not paid much attention to the dev
list. my apologies.
so to me this has not been sitting in front of me for long.
Plus
Ean Schuessler schrieb:
[..]
Now a completely separate issue is how we determine whether someone's changes are ready to go into the production repository. In a Linus style model, it would just be up to David and then maybe a lot of people would also follow Andy's branches closely (kind of like
I proposed the contributor model of branches in 2004, did not get much
support for it. someone can create their contribution for others to
evaluate when it is passed must they it can be voted on to be merged
with the trunk.
The value then, it would water down the trunk contributions.
Ean
I don't think the ASF imposes any kind of vote per trunk commit model for
revision control.
- Christian Geisert wrote:
Uh no, this isn't up for debate at the ASF ;-)
See http://www.apache.org/foundation/voting.html
--
Ean Schuessler, CTO Brainfood.com
e...@brainfood.com -
Jacques,
Thanks for your questions. I will address each one inline...
Honestly, in my initial plan I only had 4 permissions
create,read,update and delete. Then after thinking about it,
access seemed
to be a nice extra permission to limit access to applications.
Read is nothing more
in refactoring the
security framework. Could you help me with the design?
-Adrian
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009
Yeah attaching entity conditions to permissions somehow was what I had
in mind.
Another thing I thought of today was some sort of intelligent
EntityValue that restricts gets or sets based on permissions defined
on the security aware delegator. Stuff like that could pass through
to form
Great movement! Exciting!
Only one question, I read your document and I'm not sure whether it's
easy to support multiple OUs of sales, for example:
access:sfa:langhua egovernment sales unit:opportunity
access:sfa:langhua ecomerce sales unit:opportunity
access:sfa:langhua chemistry sales
Hi Andrew,
inline...
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Jacques,
Honestly, in my initial plan I only had 4 permissions create,read,update and
delete. Then after thinking about it, access seemed
to be a nice extra permission to limit access to applications. Read is nothing
--- On Sat, 5/2/09, David E Jones david.jo...@hotwaxmedia.com wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for the services versus
direct permission part anyway, and we decided long ago
interested in refactoring the
security framework. Could you help me with the design?
-Adrian
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date
--- On Sat, 5/2/09, David E Jones david.jo...@hotwaxmedia.com wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for the services versus
direct permission part anyway, and we decided long ago
:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:49 PM
It's exactly the same in fact, we have a design proposed
by somebody
let's start discussing it. Tear pieces out, replace
some
On May 3, 2009, at 10:13 AM, Andrew Zeneski wrote:
So, the revert was warranted because only you saw fit to revert it.
Maybe I should start looking over your code and reverting things I
don't agree with. That would surely drive a this community in the
right direction sarcasm.
You may
Do me a favor please! Please use simple English as this is an
international community. Too many times I cannot understand long
emails. :(
If you want to discuss something complicated, please use PMC mail list.
Regards,
Shi Yusen/Beijing Langhua Ltd.
Which parts are you having trouble understanding? I'm sure someone
(probably even the original author in most cases) would be happy to
try to clarify it for you.
-David
On May 3, 2009, at 11:20 AM, Shi Yusen wrote:
Do me a favor please! Please use simple English as this is an
David E Jones wrote:
It looks like what I was afraid of is EXACTLY what happened. Andrew and
various others seem simply not interested in feedback being convinced of
what they have presented and not wanted to admit any appearance of
fault, which appreciating and using feedback naturally does.
Andrew Zeneski wrote:
I must admit this is very disappointing, and not a very community sort
of thing I would expect from someone who is an advocate for a
community. Instead, this is a very tyrannical approach to the whole
thing and very disrespectful. So far the two people who have not seen
Inline...
Please don't revert the rest of the code. The point is that this
needs time to mature, so it should stay in there but not become the
default... not YET anyway.
I will leave the what was implemented alone for the time being.
Also, please don't be personally offended by this.
Adam Heath wrote:
Have you considered doing a git or mercurial branch of all these changes?
hg clone http://hg.webslinger.org/hg/ofbiz.apache.org/
I have that machine subscribed to the commits mailing list, and it is
automatically updated whenever a commit is done to subversion. It
even has
From: Adam Heath doo...@brainfood.com
David E Jones wrote:
It looks like what I was afraid of is EXACTLY what happened. Andrew and
various others seem simply not interested in feedback being convinced of
what they have presented and not wanted to admit any appearance of
fault, which
Mine has salsa splattered on it - I don't know what it says.
-Adrian
--- On Sun, 5/3/09, Jacques Le Roux jacques.le.r...@les7arts.com wrote:
From: Jacques Le Roux jacques.le.r...@les7arts.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date
One thing that came to mind during our discussion today and I'm not
sure how feasible it is but I'll throw it out there anyway:
Most record based permission checks come to down querying the database
for related records to check various roles and whatnot right? So what
if instead of querying
Just for discussion convenience, here are the links in Confluence and Jira I
think are related to this discussion so far
https://issues.apache.org/jira/browse/OFBIZ-2380 (main task)
http://docs.ofbiz.org/x/-B0 (Andrew's proposition)
http://docs.ofbiz.org/x/JR4 (detailed persmissions)
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
...snip...
The new authz implementation handles all of this for us. First we define the
permissions, access:example, update:example and
delete:example as seed data. These are also attached to the example admin
user's security group.
We
Jacques,
Honestly, in my initial plan I only had 4 permissions
create,read,update and delete. Then after thinking about it, access
seemed to be a nice extra permission to limit access to applications.
Read is nothing more than what view is today, the only reason for
using the name read
Are you saying that we attach some logic to the authorization API
which returns an EntityCondition object to limit the data returned in
queries? This goes well with the idea I had to add an
EntityUtil.filterByPermission() method. However, I don't think this is
something which would replace
--- On Sat, 5/2/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Saturday, May 2, 2009, 5:02 AM
One thing that came to mind during our
discussion today
On May 1, 2009, at 3:30 PM, Andrew Zeneski wrote:
Don't worry, I expected some level of resistance to a change of this
magnitude, plus this requires a very different way of thinking so I
planned on having to explain it, I tried to cover everything in the
document, but that's impossible to
I'd like to move the discussion of the new Authz security
implementation to this thread. To start off the discussion I will
briefly describe what I would like to propose as the NEW best practices.
1. Single point of contact for ALL security checks, instead of having
security embedded in
After reviewing the Asset Maintenance component's method of overriding
security, I understand the concern from Adrian in the other thread.
This is something I left off the email below so I thought I would
amend it now.
While this is a really creative workaround for the limitations in the
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com wrote:
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Subject: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 10:36 AM
1. Single point of contact for ALL security
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com wrote:
After reviewing the Asset Maintenance component's method
of overriding security, I understand the concern from Adrian
in the other thread. This is something I left off the email
below so I thought I would amend it now.
I see this new security framework as big step forward. The existing
security system is way too static, I mean permission rules are
embedded in services such that users always need ofbiz DSL (mini lang)
experts to do simple stuff (good job security, If there were customers).
New system
Don't worry, I expected some level of resistance to a change of this
magnitude, plus this requires a very different way of thinking so I
planned on having to explain it, I tried to cover everything in the
document, but that's impossible to do :)
This is VERY similar to the existing
On May 1, 2009, at 4:23 PM, Adrian Crum wrote:
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com
wrote:
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Subject: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 10:36
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com wrote:
What changed is that now the permission logic is NOT tied
directly to the service itself. The logic is tied to the
permission. So ANY call to authz.hasPermission() the EXACT
same code runs that checks the permission.
Some of these questions in the discussions so far give me the feeling
that the write up Andrew put in confluence hasn't been read, is that
the case?
Anyway I'm a +1 for the new auth framework, I think it give us more
power AND simplicity. Will it need improvement over time? of course
it
questions I am - because they weren't involved and don't understand what
you're doing.
-Adrian
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com wrote:
From: Andrew Zeneski andrew.zene...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 2:30 PM
Don't worry, I expected some level of resistance to a
change of this magnitude, plus this requires a very
different way of thinking so I planned on having to explain
it, I
: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 2:30 PM
Don't worry, I expected some level of resistance to a
change of this magnitude, plus this requires a very
different way of thinking so I planned on having to explain
it, I tried to cover
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
What do you mean by reboot this entire process? So far
you're the only person who has questioned the design...
and you already commented on it initially on the confluence
page to which Andrew responded.
That's not true:
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
Some of these questions in the discussions so far give me
the feeling that the write up Andrew put in confluence
hasn't been read, is that the case?
Anyway I'm a +1 for the new auth framework, I think it
give us more power
Well posting concerns in a new confluence page doesn't really
constitute communicating those concerns.
In my experience with the community silence has always implied either
consent or a lack of interest and when your working hard on something
you don't want to see progress stall while you
I think everyone needs to step back just a bit. Yes, some code was
written, but nothing that drastically changes anything. Actually, I
paid very close attention to make sure that this could sit on the side
lines so it could be evaluated. Very little effort has been put into
the real work
to starting
over?
-Adrian
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 5:55 PM
Well posting concerns in a new
I don't really think that is relevant, permission
services were an improvement to the existing security
framework, designing a new framework doesn't invalidate
an improvement to the old one.
Of course it is relevant! Do we need to continue to design things that
ultimately have to be
--- On Fri, 5/1/09, Andrew Zeneski andrew.zene...@hotwaxmedia.com wrote:
That said, if you do have something to add, wish to see or
just want to be involved, now is the time to be proactive!
Otherwise the effort will push forward with the people who
are indeed interested in improving security
This is one of the big reasons what I love and hate community driven
software. I don't see how what Andrew did is bad. Even though it was
personal communication but I know Andrew only started after Adrian and
Jacques showed interest by commenting on the page.
Andrew has been actively
How about we start over and collaborate on a design? Is that so much different?
-Adrian
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Andrew Zeneski wrote:
So, instead of discussing what should or should not have been done, look
at the fact that this entire effort is sitting in the community's lap
right this minute. But instead of reviewing what is there, pointing out
weaknesses offering suggestions or anything constructive
--- On Fri, 5/1/09, Adam Heath doo...@brainfood.com wrote:
pps: I'm very interested in the idea of this. A single
api to be used
by any class for security, would be very welcome by me.
I'm very interested too, as well as others. I have some ideas also. But there
are a few in this thread
on a design? Is that so much
different?
-Adrian
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:30 PM
--- On Fri, 5/1/09, Adam Heath doo...@brainfood.com wrote:
Plus, if the new system can run in parallel, and classes
can be
changed over to it one at a time, then what is the big
deal?
The big deal is in recoding everything. Your comment reminds me of one of
David's favorite expressions - So
Where did that come from??!!
--- On Fri, 5/1/09, Adrian Crum adrian.c...@yahoo.com wrote:
From: Adrian Crum adrian.c...@yahoo.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:45 PM
--- On Fri, 5/1/09, Adam Heath doo
...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:49 PM
It's exactly the same in fact, we have a design proposed
by somebody
let's start discussing it. Tear pieces out, replace
some, improve
others, whatever
Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:49 PM
It's exactly the same in fact, we have a design proposed
by somebody
let's start discussing it. Tear pieces out, replace
some, improve
others, whatever at least we have a starting point.
Regards
--- On Fri, 5/1/09, Scott Gray scott.g...@hotwaxmedia.com wrote:
From: Scott Gray scott.g...@hotwaxmedia.com
Subject: Re: Authz API Discussion (was re: svn commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 8:06 PM
So what are you suggesting, scrap the design and start from
On May 1, 2009, at 10:19 PM, Adrian Crum wrote:
--- On Fri, 5/1/09, Anil Patel anil.pa...@hotwaxmedia.com wrote:
This is one of the big reasons what I love and hate
community driven software. I don't see how what Andrew
did is bad. Even though it was personal communication but I
know Andrew
: Authz API Discussion (was re:
svn
commit: r770084)
To: dev@ofbiz.apache.org
Date: Friday, May 1, 2009, 7:30 PM
This discussion is going no where fast,
how about
we back
track to Andrew's last email and start
actually
discussing the design. Nothing is being
foisted
on anybody
63 matches
Mail list logo
