The current SVN is doing an AND on the base-permission list.
To recap: I added the ADMIN permission check to the main application bar logic. When I did that I
also changed the logic to OR the base-permission list - based upon my misunderstanding of the usage
of the base-permission list. Jacopo caught that and changed it back to ANDing the base-permission list.
At any rate, the discussion has been informative. David - thanks again for your
input!
David E Jones wrote:
I haven't reviewed the patch, but just to make sure we're all on the
same page: it is doing an AND, right?
In other words it requires all permissions in the list, not allowing
just any?
Personally I don't think either AND or OR is implied by the attribute
or it's usage, just a matter of what is most useful and then perhaps
documenting it with an annotation in the XSD file or something, and I
think based on the discussions I remember (I don't remember who
implemented that though, perhaps Andrew Z.) we decided AND would be
more useful.
-David
On Oct 17, 2007, at 11:27 AM, Adrian Crum wrote:
Yes, your patch is correct. Thanks for catching that!
Jacopo Cappellato wrote:
So, at the end of the story... is my last patch correct, right?
Sorry, but I'm a bit tired today and I'm getting a bit dumb.
Jacopo
Adrian Crum wrote:
David,
Thanks for your input!
Si makes a good point about permissions that have unexpected side-
effects. Let's say you're using some of the Party Manager screens
in a custom app. Inside those screens are permission checks for the
PARTYMGR_VIEW permission, so you give that permission to your
custom app users. Oops, now they have access to the Party Manager
application. By ANDing the base-permission list, if they don't have
the OFBTOOLS permission, then the Party Manager application doesn't
appear.
The OFBTOOLS permission idea solves the problem. It just seems
counter-intuitive in the base-permission list.
-Adrian
David E Jones wrote:
Not sure where Si got his notes, but I think what you are writing
is correct Adrian.
If I remember right from the initial discussions around this the
point was to be able to add on other applications and have more
control over which a user can see, the common scenario being that
you would want to be able to setup a user that could see the
add-on application (even though it does have a security
permission), but not the base ofbiz applications. With that you
could just not include the OFBTOOLS permission in your add-on
application and off you go...
-David
On Oct 17, 2007, at 10:44 AM, Adrian Crum wrote:
Jacopo,
Doing a Google search, I found these notes from Si:
http://www.opensourcestrategies.com/ofbiz/security.php
According to Si, the list of base permissions should be ANDed,
not ORed. I don't know the reasoning for that, however.
-Adrian
Jacopo Cappellato wrote:
Adrian,
I think that you could be right.
I'm not sure I understand the meaning of the OFBTOOLS
permission, but I don't think it was intended as the base
permission for the Webtools application... but I could be wrong.
Any hints from others?
Jacopo
Adrian Crum wrote:
Jacopo,
How was the original logic incorrect? The original logic was this:
For each application:
Permission to use the application defaults to false
If the user has one of the permissions in the application's
base-permission list,
OR if the base-permission list contains "NONE", then
permission to use
the application is true
The reason all of the applications became visible to a user
with the OFBTOOLS permission is because all of the
applications have the OFBTOOLS permission in their base-
permission list.
My understanding is that the OFBTOOLS permission was intended
to grant access to the Webtools application. I don't know why
it has been included in every other application.
-Adrian
