You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ofbiz.apache.org by ja...@apache.org on 2009/04/30 08:23:19 UTC
svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/
entitydef/ security/ servicedef/ widget/example/
Author: jaz
Date: Thu Apr 30 06:23:18 2009
New Revision: 770084
URL: http://svn.apache.org/viewvc?rev=770084&view=rev
Log:
Refactored Example Application to use new security mechanics - JIRA OFBIZ-2392
Added:
ofbiz/trunk/framework/example/security/
ofbiz/trunk/framework/example/security/CreateExample.groovy
ofbiz/trunk/framework/example/security/UpdateExample.groovy
Modified:
ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
ofbiz/trunk/framework/example/entitydef/entitymodel.xml
ofbiz/trunk/framework/example/ofbiz-component.xml
ofbiz/trunk/framework/example/servicedef/services.xml
ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml
ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml
ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml
Modified: ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/config/ExampleUiLabels.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/config/ExampleUiLabels.xml (original)
+++ ofbiz/trunk/framework/example/config/ExampleUiLabels.xml Thu Apr 30 06:23:18 2009
@@ -466,13 +466,13 @@
<value xml:lang="it">DA FARE</value>
</property>
<property key="ExampleViewPermissionError">
- <value xml:lang="en">You do not have permission to view this page. ("EXAMPLE_VIEW" or "EXAMPLE_ADMIN" needed)</value>
- <value xml:lang="fr">Vous n'avez pas l'autorisation de voir cette page ("EXAMPLE_VIEW" ou "EXAMPLE_ADMIN" nécessaire)</value>
- <value xml:lang="it">Tu non sei autorizzare a vedere questa pagina. (Permesso "EXAMPLE_VIEW" o "EXAMPLE_ADMIN" necessario)</value>
- <value xml:lang="ro">Nu esti autorizat sa vezi aceasta pagina. (Este necesar Permisul "EXAMPLE_VIEW" sau "EXAMPLE_ADMIN")</value>
- <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав Ð´Ð»Ñ Ð¿ÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "EXAMPLE_VIEW" или "EXAMPLE_ADMIN")</value>
- <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸à¸à¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹ (หà¸à¹à¸² "EXAMPLE_VIEW" หรืภ"EXAMPLE_ADMIN" à¸à¸µà¹à¸à¹à¸à¸à¸à¸²à¸£)</value>
- <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé¢çæéã(éè¦"EXAMPLE_VIEW"æ"EXAMPLE_ADMIN")</value>
+ <value xml:lang="en">You do not have permission to view this page. ("access:example" needed)</value>
+ <value xml:lang="fr">Vous n'avez pas l'autorisation de voir cette page ("access:example" nécessaire)</value>
+ <value xml:lang="it">Tu non sei autorizzare a vedere questa pagina. (Permesso "access:example" necessario)</value>
+ <value xml:lang="ro">Nu esti autorizat sa vezi aceasta pagina. (Este necesar Permisul "access:example")</value>
+ <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав Ð´Ð»Ñ Ð¿ÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "access:example")</value>
+ <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸à¸à¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹ (หà¸à¹à¸² "access:example" à¸à¸µà¹à¸à¹à¸à¸à¸à¸²à¸£)</value>
+ <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé¢çæéã(éè¦"access:example")</value>
</property>
<property key="ExampleWelcome">
<value xml:lang="en">Welcome to the Example application!</value>
Modified: ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/data/ExampleSecurityData.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/data/ExampleSecurityData.xml (original)
+++ ofbiz/trunk/framework/example/data/ExampleSecurityData.xml Thu Apr 30 06:23:18 2009
@@ -19,16 +19,30 @@
-->
<entity-engine-xml>
<!-- Example security -->
- <SecurityPermission description="View operations in the Example Management Screens." permissionId="EXAMPLE_VIEW"/>
- <SecurityPermission description="Create operations in the Example Management Screens." permissionId="EXAMPLE_CREATE"/>
- <SecurityPermission description="Update operations in the Example Management Screens." permissionId="EXAMPLE_UPDATE"/>
- <SecurityPermission description="Delete operations in the Example Management Screens." permissionId="EXAMPLE_DELETE"/>
- <SecurityPermission description="ALL operations in the Example Management Screens." permissionId="EXAMPLE_ADMIN"/>
- <SecurityGroupPermission groupId="FULLADMIN" permissionId="EXAMPLE_ADMIN"/>
- <SecurityGroupPermission groupId="FLEXADMIN" permissionId="EXAMPLE_CREATE"/>
- <SecurityGroupPermission groupId="FLEXADMIN" permissionId="EXAMPLE_DELETE"/>
- <SecurityGroupPermission groupId="FLEXADMIN" permissionId="EXAMPLE_UPDATE"/>
- <SecurityGroupPermission groupId="FLEXADMIN" permissionId="EXAMPLE_VIEW"/>
- <SecurityGroupPermission groupId="VIEWADMIN" permissionId="EXAMPLE_VIEW"/>
- <SecurityGroupPermission groupId="BIZADMIN" permissionId="EXAMPLE_ADMIN"/>
+ <SecurityPermission description="ACCESS the Example Application" permissionId="access:example"/>
+ <SecurityPermission description="CREATE operations in the Example Application" permissionId="create:example" dynamicAccess="component://example/security/CreateExample.groovy"/>
+ <SecurityPermission description="READ operations in the Example Application" permissionId="read:example"/>
+ <SecurityPermission description="UPDATE operations in the Example Application" permissionId="update:example" dynamicAccess="component://example/security/UpdateExample.groovy"/>
+ <SecurityPermission description="DELETE operations in the Example Application" permissionId="delete:example"/>
+
+ <SecurityPermission description="CREATE STATUS operations in the Example Application" permissionId="create:example:status"/>
+ <SecurityPermission description="READ STATUS operations in the Example Application" permissionId="read:example:status"/>
+ <SecurityPermission description="UPDATE STATUS operations in the Example Application" permissionId="update:example:status"/>
+ <SecurityPermission description="DELETE STATUS operations in the Example Application" permissionId="delete:example:status"/>
+
+ <SecurityPermission description="CREATE ITEM operations in the Example Application" permissionId="create:example:item"/>
+ <SecurityPermission description="READ ITEM operations in the Example Application" permissionId="read:example:item"/>
+ <SecurityPermission description="UPDATE ITEM operations in the Example Application" permissionId="update:example:item"/>
+ <SecurityPermission description="DELETE ITEM operations in the Example Application" permissionId="delete:example:item"/>
+
+ <SecurityPermission description="CREATE FEATURE operations in the Example Application" permissionId="create:example:feature"/>
+ <SecurityPermission description="READ ITEM operations in the Example Application" permissionId="read:example:feature"/>
+ <SecurityPermission description="UPDATE ITEM operations in the Example Application" permissionId="update:example:feature"/>
+ <SecurityPermission description="DELETE ITEM operations in the Example Application" permissionId="delete:example:feature"/>
+
+ <SecurityGroupPermission groupId="BIZADMIN" permissionId="access:example"/>
+ <SecurityGroupPermission groupId="BIZADMIN" permissionId="create:example"/>
+ <SecurityGroupPermission groupId="BIZADMIN" permissionId="read:example"/>
+ <SecurityGroupPermission groupId="BIZADMIN" permissionId="update:example"/>
+ <SecurityGroupPermission groupId="BIZADMIN" permissionId="delete:example"/>
</entity-engine-xml>
Modified: ofbiz/trunk/framework/example/entitydef/entitymodel.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/entitydef/entitymodel.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/entitydef/entitymodel.xml (original)
+++ ofbiz/trunk/framework/example/entitydef/entitymodel.xml Thu Apr 30 06:23:18 2009
@@ -55,6 +55,7 @@
<field name="exampleDate" type="date-time"></field>
<field name="anotherDate" type="date-time"></field>
<field name="anotherText" type="long-varchar"></field>
+ <field name="createdByUser" type="id-vlong-ne"></field>
<prim-key field="exampleId"/>
<relation type="one" fk-name="EXMPL_TYP" rel-entity-name="ExampleType">
<key-map field-name="exampleTypeId"/>
@@ -62,6 +63,9 @@
<relation type="one" fk-name="EXMPL_STTS" rel-entity-name="StatusItem">
<key-map field-name="statusId"/>
</relation>
+ <relation type="one" fk-name="EXMPL_USER" rel-entity-name="UserLogin">
+ <key-map field-name="createdByUser" rel-field-name="userLoginId"/>
+ </relation>
</entity>
<entity entity-name="ExampleItem" package-name="org.ofbiz.example.example" title="Example Item Entity" default-resource-name="ExampleEntityLabels">
<field name="exampleId" type="id-ne"></field>
Modified: ofbiz/trunk/framework/example/ofbiz-component.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/ofbiz-component.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/ofbiz-component.xml (original)
+++ ofbiz/trunk/framework/example/ofbiz-component.xml Thu Apr 30 06:23:18 2009
@@ -54,6 +54,6 @@
menu-name="secondary"
server="default-server"
location="webapp/example"
- base-permission="OFBTOOLS,EXAMPLE"
+ base-permission="access:example"
mount-point="/example"/>
</ofbiz-component>
Added: ofbiz/trunk/framework/example/security/CreateExample.groovy
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/CreateExample.groovy?rev=770084&view=auto
==============================================================================
--- ofbiz/trunk/framework/example/security/CreateExample.groovy (added)
+++ ofbiz/trunk/framework/example/security/CreateExample.groovy Thu Apr 30 06:23:18 2009
@@ -0,0 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+ // this dynamic access grants ANYONE access
+ return true;
\ No newline at end of file
Added: ofbiz/trunk/framework/example/security/UpdateExample.groovy
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/UpdateExample.groovy?rev=770084&view=auto
==============================================================================
--- ofbiz/trunk/framework/example/security/UpdateExample.groovy (added)
+++ ofbiz/trunk/framework/example/security/UpdateExample.groovy Thu Apr 30 06:23:18 2009
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.ofbiz.base.util.Debug;
+
+exampleId = permissionContext.get("exampleId");
+Debug.logInfo("Groovy DA Context : " + permissionContext, "groovy");
+Debug.logInfo("Calling UpdateExample.groovy - " + exampleId, "groovy");
+if (exampleId != null) {
+ example = delegator.findOne("Example", [exampleId : exampleId], true);
+ Debug.logInfo("Example : " + example, "groovy");
+
+ if (example.createdByUser == null || userId.equals(example.createdByUser)) {
+ return true;
+ }
+}
+
+return false;
Modified: ofbiz/trunk/framework/example/servicedef/services.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/servicedef/services.xml (original)
+++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30 06:23:18 2009
@@ -27,29 +27,37 @@
<!-- Example & Related Services -->
<service name="createExample" default-entity-name="Example" engine="entity-auto" invoke="create" auth="true">
<description>Create a Example</description>
- <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="create:example"/>
+ </required-permissions>
<auto-attributes include="pk" mode="OUT" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
<override name="exampleTypeId" optional="false"/>
<override name="statusId" optional="false"/>
- <override name="exampleName" optional="false"/>
+ <override name="exampleName" optional="false"/>
</service>
<service name="updateExample" default-entity-name="Example" engine="entity-auto" invoke="update" auth="true">
<description>Update a Example</description>
- <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="update:example:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
<attribute name="oldStatusId" type="String" mode="OUT" optional="false"/>
</service>
<service name="deleteExample" default-entity-name="Example" engine="entity-auto" invoke="delete" auth="true">
<description>Delete a Example</description>
- <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="delete:example:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
</service>
<service name="createExampleStatus" default-entity-name="ExampleStatus" engine="simple"
location="component://example/script/org/ofbiz/example/example/ExampleServices.xml" invoke="createExampleStatus" auth="true">
<description>Create a ExampleStatus</description>
- <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="update:example:status:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="all" mode="IN" optional="false">
<exclude field-name="statusDate"/>
<exclude field-name="statusEndDate"/>
@@ -58,7 +66,9 @@
<service name="createExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="create" auth="true">
<description>Create a ExampleItem</description>
- <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="create:example:item:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
<override name="exampleItemSeqId" mode="OUT"/> <!-- make this OUT rather than IN, we will automatically generate the next sub-sequence ID -->
@@ -66,60 +76,78 @@
</service>
<service name="updateExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="update" auth="true">
<description>Update a ExampleItem</description>
- <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="update:example:item:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
</service>
<service name="deleteExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="delete" auth="true">
<description>Delete a ExampleItem</description>
- <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="delete:example:item:${exampleId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
</service>
<!-- ExampleFeature Services -->
<service name="createExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="create" auth="true">
<description>Create a ExampleFeature</description>
- <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="create:example:feature"/>
+ </required-permissions>
<auto-attributes include="pk" mode="OUT" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
<override name="description" optional="false"/>
</service>
<service name="updateExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="update" auth="true">
<description>Update a ExampleFeature</description>
- <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="update:example:feature"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
</service>
<service name="deleteExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="delete" auth="true">
<description>Delete a ExampleFeature</description>
- <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="delete:example:feature"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
</service>
<service name="createExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="create" auth="true">
<description>Create a ExampleFeatureAppl</description>
- <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="create:example:feature:${exampleFeatureId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
<override name="fromDate" optional="true"/>
</service>
<service name="updateExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="update" auth="true">
<description>Update a ExampleFeatureAppl</description>
- <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="update:example:feature:${exampleFeatureId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
<auto-attributes include="nonpk" mode="IN" optional="true"/>
</service>
<service name="deleteExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="delete" auth="true">
<description>Delete a ExampleFeatureAppl</description>
- <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
+ <required-permissions join-type="AND">
+ <check-permission permission="delete:example:feature:${exampleFeatureId}"/>
+ </required-permissions>
<auto-attributes include="pk" mode="IN" optional="false"/>
</service>
<!-- Permission Services -->
+ <!-- @deprecated
<service name="exampleGenericPermission" engine="simple"
location="component://example/script/org/ofbiz/example/ExamplePermissionServices.xml" invoke="exampleGenericPermission">
<implements service="permissionInterface"/>
</service>
+ -->
<!-- Example ServiceTest Service -->
<service name="testCreateExampleService" engine="simple"
Modified: ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/CommonScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/CommonScreens.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/CommonScreens.xml Thu Apr 30 06:23:18 2009
@@ -71,7 +71,7 @@
<section>
<condition>
<and>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
<not><if-empty field="example"/></not>
</and>
</condition>
@@ -82,9 +82,9 @@
</decorator-section>
<decorator-section name="body">
<section>
- <!-- do check for EXAMPLE, _VIEW permission -->
+ <!-- do check for access:example permission -->
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<section>
@@ -135,7 +135,7 @@
<section>
<condition>
<and>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
<not><if-empty field="exampleFeature"/></not>
</and>
</condition>
@@ -148,7 +148,7 @@
<section>
<!-- do check for EXAMPLE, _VIEW permission -->
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<section>
Modified: ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml Thu Apr 30 06:23:18 2009
@@ -34,7 +34,7 @@
<decorator-section name="body">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<container style="h1"><label>${uiLabelMap[titleProperty]}</label></container>
@@ -68,7 +68,7 @@
<screen name="ListExampleFormOnly">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<actions>
<!-- NOTE: these are needed because this may be run as a top level screen and would have no decorator -->
@@ -84,7 +84,7 @@
<screen name="CreateExampleFormOnly">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<actions>
<!-- these are only needed so that when bsh evaluates use-when attributes these will exist and not cause an error -->
Modified: ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml Thu Apr 30 06:23:18 2009
@@ -34,7 +34,7 @@
<decorator-section name="body">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<decorator-screen name="FindScreenDecorator" location="component://common/widget/CommonScreens.xml">
@@ -98,7 +98,7 @@
<screen name="LookupExampleFeature">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<actions>
<property-map resource="ExampleUiLabels" map-name="uiLabelMap" global="true"/>
Modified: ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleForms.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/ExampleForms.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/ExampleForms.xml Thu Apr 30 06:23:18 2009
@@ -142,6 +142,8 @@
<field name="displayAnotherText" use-when="example!=null&&example.get("anotherText")!=null">
<display description="${example.anotherText}"/>
</field>
+ <field name="createdByUser" use-when="example==null"><hidden value="${userLogin.userLoginId}"/></field>
+ <field name="createdByUser" use-when="example!=null"><hidden/></field>
<field name="submitButton" use-when="example==null" title="${uiLabelMap.CommonCreate}"><submit button-type="button"/></field>
<field name="submitButton" use-when="example!=null" title="${uiLabelMap.CommonUpdate}"><submit button-type="button"/></field>
</form>
Modified: ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml Thu Apr 30 06:23:18 2009
@@ -34,7 +34,7 @@
<decorator-section name="body">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<decorator-screen name="FindScreenDecorator" location="component://common/widget/CommonScreens.xml">
Modified: ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml (original)
+++ ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml Thu Apr 30 06:23:18 2009
@@ -31,7 +31,7 @@
<decorator-section name="body">
<section>
<condition>
- <if-has-permission permission="EXAMPLE" action="_VIEW"/>
+ <if-has-permission permission="access:example"/>
</condition>
<widgets>
<container style="h1"><label>${uiLabelMap.PageTitleFormWidgetExamples}</label></container>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./
config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David Welton <da...@dedasys.com>.
> - <value xml:lang="it">Tu non sei autorizzare a vedere questa pagina. (Permesso "EXAMPLE_VIEW" o "EXAMPLE_ADMIN" necessario)</value>
BTW, that Italian isn't quite correct...
--
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
Sent from Padova, PD, Italy
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
No problem, I thought I posted this to the dev list last week, I
wonder where I sent it...
On Apr 30, 2009, at 2:28 PM, Jacques Le Roux wrote:
> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>> Looks like you probably missed the big design document which
>> explains everything:
>> http://docs.ofbiz.org/x/-B0
>> http://docs.ofbiz.org/x/JR4
>
> Great stuff, thanks Andrew!
>
> Jacques
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Andrew Zeneski" <an...@hotwaxmedia.com>
> Looks like you probably missed the big design document which explains
> everything:
> http://docs.ofbiz.org/x/-B0
> http://docs.ofbiz.org/x/JR4
Great stuff, thanks Andrew!
Jacques
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@yahoo.com>.
As I mentioned in another reply, the permission expressions could replace scripts. I agree there would probably be little use for them in the UI.
-Adrian
--- On Thu, 4/30/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> Subject: Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
> To: dev@ofbiz.apache.org
> Date: Thursday, April 30, 2009, 7:31 PM
> I'm trying to come up with a use case where this sort of
> logic would be applicable, but I just cannot think of any. I
> can think of cases where we will conditionally want to check
> a single permission but OR/AND permissions together for a UI
> element?
>
> When displaying a list of items, I might add a link to an
> update form, in which I would only show the link if update
> permission available. Same with delete, but I wouldn't
> check these in the same place, rather with each link.
>
> Also, I might use <display/> for read only users
> instead of text boxes (I really like Jacopo's use-when
> idea). But when would I really ever want to check them in an
> AND/OR fashion?
>
> Keeping in mind now, that the permission system handles
> granularity, as long as we are intelligent when defining
> permissions I believe a single permissions should be able to
> handle most cases. With the exception of UIs where we would
> want to display different things based on a different base
> permission, even then a single call using the new
> findMatchingPermissions() would totally do the trick.
>
> Andrew
>
> On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote:
>
> > I like that idea. Less chance that an unintended
> conversion would occur.
> >
> > -Adrian
> >
> > Scott Gray wrote:
> >> FYI and I only realized this the other day but
> beanshell supports exactly this type of feature where you
> can specify things @and, @or and etc. for use in xml files
> http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities
> >> I wonder if we do this it might be worth following
> the same convention.
> >> Regards
> >> Scott
> >> HotWax Media
> >> http://www.hotwaxmedia.com
> <http://www.hotwaxmedia.com/>
> >> On 1/05/2009, at 5:34 AM, Jacopo Cappellato wrote:
> >>> Adrian,
> >>>
> >>> this is really interesting.
> >>> However I think it is time to start thinking
> to define our own xml friendly keywords for && and
> || operators; I would like to express that statement with
> something like this:
> >>>
> >>> <set field="hasPermission"
> value="${(hasPermission['update:context1'] OR
> hasPermission['update:context2']) AND
> hasPermission['update:context3']}"
> type="Boolean"/>
> >>>
> >>> Jacopo
> >>>
> >>>
> >>> On Apr 30, 2009, at 7:20 PM, Adrian Crum
> wrote:
> >>>
> >>>> <set field="hasPermission"
> value="${(hasPermission['update:context1'] ||
> hasPermission['update:context2']) &&
> hasPermission['update:context3']}"
> type="Boolean"/>
> >>>>
> >>>> or something like that. I'm still
> working out the details.
> >>>>
> >>>> -Adrian
> >>>>
> >>>> Andrew Zeneski wrote:
> >>>>> That sounds cool. I'm not sure
> what that would really look like, but nevertheless sounds
> really cool! :) If you need anything from me let me know...
> >>>>> Andrew
> >>>>> On Apr 30, 2009, at 1:00 PM, Adrian
> Crum wrote:
> >>>>>> Andrew Zeneski wrote:
> >>>>>>> I'd be happy to discuss
> additional changes as well (which aren't yet documented)
> like adding support to check multiple permissions at once,
> returning a Map of results from that permission check. So,
> if you or anyone else has a wish list for security, let me
> know so I can get it all incorporated at the same time.
> >>>>>>
> >>>>>> Btw, I'm working on adding an
> extension to the UEL that will allow permission expressions.
> >>>>>>
> >>>>>>
> >>>>>> -Adrian
> >>>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I'm trying to come up with a use case where this sort of logic would
be applicable, but I just cannot think of any. I can think of cases
where we will conditionally want to check a single permission but OR/
AND permissions together for a UI element?
When displaying a list of items, I might add a link to an update form,
in which I would only show the link if update permission available.
Same with delete, but I wouldn't check these in the same place, rather
with each link.
Also, I might use <display/> for read only users instead of text boxes
(I really like Jacopo's use-when idea). But when would I really ever
want to check them in an AND/OR fashion?
Keeping in mind now, that the permission system handles granularity,
as long as we are intelligent when defining permissions I believe a
single permissions should be able to handle most cases. With the
exception of UIs where we would want to display different things based
on a different base permission, even then a single call using the new
findMatchingPermissions() would totally do the trick.
Andrew
On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote:
> I like that idea. Less chance that an unintended conversion would
> occur.
>
> -Adrian
>
> Scott Gray wrote:
>> FYI and I only realized this the other day but beanshell supports
>> exactly this type of feature where you can specify things @and, @or
>> and etc. for use in xml files http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities
>> I wonder if we do this it might be worth following the same
>> convention.
>> Regards
>> Scott
>> HotWax Media
>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>> On 1/05/2009, at 5:34 AM, Jacopo Cappellato wrote:
>>> Adrian,
>>>
>>> this is really interesting.
>>> However I think it is time to start thinking to define our own xml
>>> friendly keywords for && and || operators; I would like to express
>>> that statement with something like this:
>>>
>>> <set field="hasPermission" value="$
>>> {(hasPermission['update:context1'] OR
>>> hasPermission['update:context2']) AND
>>> hasPermission['update:context3']}" type="Boolean"/>
>>>
>>> Jacopo
>>>
>>>
>>> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>>>
>>>> <set field="hasPermission" value="$
>>>> {(hasPermission['update:context1'] ||
>>>> hasPermission['update:context2']) &&
>>>> hasPermission['update:context3']}" type="Boolean"/>
>>>>
>>>> or something like that. I'm still working out the details.
>>>>
>>>> -Adrian
>>>>
>>>> Andrew Zeneski wrote:
>>>>> That sounds cool. I'm not sure what that would really look like,
>>>>> but nevertheless sounds really cool! :) If you need anything
>>>>> from me let me know...
>>>>> Andrew
>>>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>>>> Andrew Zeneski wrote:
>>>>>>> I'd be happy to discuss additional changes as well (which
>>>>>>> aren't yet documented) like adding support to check multiple
>>>>>>> permissions at once, returning a Map of results from that
>>>>>>> permission check. So, if you or anyone else has a wish list
>>>>>>> for security, let me know so I can get it all incorporated at
>>>>>>> the same time.
>>>>>>
>>>>>> Btw, I'm working on adding an extension to the UEL that will
>>>>>> allow permission expressions.
>>>>>>
>>>>>>
>>>>>> -Adrian
>>>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
I like that idea. Less chance that an unintended conversion would occur.
-Adrian
Scott Gray wrote:
> FYI and I only realized this the other day but beanshell supports
> exactly this type of feature where you can specify things @and, @or and
> etc. for use in xml
> files http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities
>
> I wonder if we do this it might be worth following the same convention.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>
> On 1/05/2009, at 5:34 AM, Jacopo Cappellato wrote:
>
>> Adrian,
>>
>> this is really interesting.
>> However I think it is time to start thinking to define our own xml
>> friendly keywords for && and || operators; I would like to express
>> that statement with something like this:
>>
>> <set field="hasPermission" value="${(hasPermission['update:context1']
>> OR hasPermission['update:context2']) AND
>> hasPermission['update:context3']}" type="Boolean"/>
>>
>> Jacopo
>>
>>
>> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>>
>>> <set field="hasPermission" value="${(hasPermission['update:context1']
>>> || hasPermission['update:context2']) &&
>>> hasPermission['update:context3']}" type="Boolean"/>
>>>
>>> or something like that. I'm still working out the details.
>>>
>>> -Adrian
>>>
>>> Andrew Zeneski wrote:
>>>> That sounds cool. I'm not sure what that would really look like, but
>>>> nevertheless sounds really cool! :) If you need anything from me let
>>>> me know...
>>>> Andrew
>>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>>> Andrew Zeneski wrote:
>>>>>> I'd be happy to discuss additional changes as well (which aren't
>>>>>> yet documented) like adding support to check multiple permissions
>>>>>> at once, returning a Map of results from that permission check.
>>>>>> So, if you or anyone else has a wish list for security, let me
>>>>>> know so I can get it all incorporated at the same time.
>>>>>
>>>>> Btw, I'm working on adding an extension to the UEL that will allow
>>>>> permission expressions.
>>>>>
>>>>>
>>>>> -Adrian
>>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Scott Gray <sc...@hotwaxmedia.com>.
FYI and I only realized this the other day but beanshell supports
exactly this type of feature where you can specify things @and, @or
and etc. for use in xml files http://www.beanshell.org/manual/syntax.html#Document_Friendly_Entities
I wonder if we do this it might be worth following the same convention.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 1/05/2009, at 5:34 AM, Jacopo Cappellato wrote:
> Adrian,
>
> this is really interesting.
> However I think it is time to start thinking to define our own xml
> friendly keywords for && and || operators; I would like to express
> that statement with something like this:
>
> <set field="hasPermission" value="$
> {(hasPermission['update:context1'] OR
> hasPermission['update:context2']) AND
> hasPermission['update:context3']}" type="Boolean"/>
>
> Jacopo
>
>
> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>
>> <set field="hasPermission" value="$
>> {(hasPermission['update:context1'] ||
>> hasPermission['update:context2']) &&
>> hasPermission['update:context3']}" type="Boolean"/>
>>
>> or something like that. I'm still working out the details.
>>
>> -Adrian
>>
>> Andrew Zeneski wrote:
>>> That sounds cool. I'm not sure what that would really look like,
>>> but nevertheless sounds really cool! :) If you need anything from
>>> me let me know...
>>> Andrew
>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>> Andrew Zeneski wrote:
>>>>> I'd be happy to discuss additional changes as well (which aren't
>>>>> yet documented) like adding support to check multiple
>>>>> permissions at once, returning a Map of results from that
>>>>> permission check. So, if you or anyone else has a wish list for
>>>>> security, let me know so I can get it all incorporated at the
>>>>> same time.
>>>>
>>>> Btw, I'm working on adding an extension to the UEL that will
>>>> allow permission expressions.
>>>>
>>>>
>>>> -Adrian
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
What I have in mind with UEL is different. The plan is to be able to
write a permissions expression that can replace many lines of
mini-language code.
Btw, I decided to use UEL functions instead of extending the syntax.
-Adrian
Andrew Zeneski wrote:
> Not really, I just implemented what we were talking about offline, its
> called findMatchingPermissions(). So, now you can check
> "(read|update|delete):party:10000" and it will return you a map
> containing :
>
> read:party:10000 = (true|false)
> update:party:10000 = (true|false)
> delete:party:10000 = (true|false)
>
> This will only work for the base permissions (access, create, read,
> update, delete) but it should be helpful.
>
> On Apr 30, 2009, at 2:15 PM, Adrian Crum wrote:
>
>> I'm even hesitant about making this permission extension. I would
>> rather see the security component handle permission expressions, but
>> that would require a lot of coding.
>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Not really, I just implemented what we were talking about offline, its
called findMatchingPermissions(). So, now you can check "(read|update|
delete):party:10000" and it will return you a map containing :
read:party:10000 = (true|false)
update:party:10000 = (true|false)
delete:party:10000 = (true|false)
This will only work for the base permissions (access, create, read,
update, delete) but it should be helpful.
On Apr 30, 2009, at 2:15 PM, Adrian Crum wrote:
> I'm even hesitant about making this permission extension. I would
> rather see the security component handle permission expressions, but
> that would require a lot of coding.
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@hlmksw.com>
> We could. It would be an easy change to make. I would like to think about it for a while. Maybe even hear from others on the
> subject.
For me it's not a problem using && or || instead of AND or OR. We are all acquainted to this and this will be used only by devs. But
if at some point it's easy to do, why not, yes!
> I've been trying to move the project in the other direction - get the OFBiz-specific syntax out of the expressions. From my
> perspective, the less we mess around with syntax extensions, the fewer bugs we will encounter.
+1
> A good example is the problems encountered and the work required to support auto-vivify. In that case, it was worth working on
> because that is a very powerful and needful extension.
>
> I'm even hesitant about making this permission extension. I would rather see the security component handle permission expressions,
> but that would require a lot of coding.
I'd wait to have the new stuff in place and used/tested some weeks before playing with this. I mean commits, of course playing
locally should not be a problem.
My 2cts
Jacques
> -Adrian
>
> Jacopo Cappellato wrote:
>> I know this, but couldn't we replace them before calling the UEL processor?
>>
>> Jacopo
>>
>> On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote:
>>
>>> Those keywords are not recognized by UEL.
>>>
>>> -Adrian
>>>
>>> Jacopo Cappellato wrote:
>>>> Adrian,
>>>> this is really interesting.
>>>> However I think it is time to start thinking to define our own xml friendly keywords for && and || operators; I would like to
>>>> express that statement with something like this:
>>>> <set field="hasPermission" value="${(hasPermission['update:context1'] OR hasPermission['update:context2']) AND
>>>> hasPermission['update:context3']}" type="Boolean"/>
>>>> Jacopo
>>>> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>>>>> <set field="hasPermission" value="${(hasPermission['update:context1'] || hasPermission['update:context2']) &&
>>>>> hasPermission['update:context3']}" type="Boolean"/>
>>>>>
>>>>> or something like that. I'm still working out the details.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Andrew Zeneski wrote:
>>>>>> That sounds cool. I'm not sure what that would really look like, but nevertheless sounds really cool! :) If you need anything
>>>>>> from me let me know...
>>>>>> Andrew
>>>>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>>>>> Andrew Zeneski wrote:
>>>>>>>> I'd be happy to discuss additional changes as well (which aren't yet documented) like adding support to check multiple
>>>>>>>> permissions at once, returning a Map of results from that permission check. So, if you or anyone else has a wish list for
>>>>>>>> security, let me know so I can get it all incorporated at the same time.
>>>>>>>
>>>>>>> Btw, I'm working on adding an extension to the UEL that will allow permission expressions.
>>>>>>>
>>>>>>>
>>>>>>> -Adrian
>>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
We could. It would be an easy change to make. I would like to think
about it for a while. Maybe even hear from others on the subject.
I've been trying to move the project in the other direction - get the
OFBiz-specific syntax out of the expressions. From my perspective, the
less we mess around with syntax extensions, the fewer bugs we will
encounter.
A good example is the problems encountered and the work required to
support auto-vivify. In that case, it was worth working on because that
is a very powerful and needful extension.
I'm even hesitant about making this permission extension. I would rather
see the security component handle permission expressions, but that would
require a lot of coding.
-Adrian
Jacopo Cappellato wrote:
> I know this, but couldn't we replace them before calling the UEL processor?
>
> Jacopo
>
> On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote:
>
>> Those keywords are not recognized by UEL.
>>
>> -Adrian
>>
>> Jacopo Cappellato wrote:
>>> Adrian,
>>> this is really interesting.
>>> However I think it is time to start thinking to define our own xml
>>> friendly keywords for && and || operators; I would like to express
>>> that statement with something like this:
>>> <set field="hasPermission" value="${(hasPermission['update:context1']
>>> OR hasPermission['update:context2']) AND
>>> hasPermission['update:context3']}" type="Boolean"/>
>>> Jacopo
>>> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>>>> <set field="hasPermission"
>>>> value="${(hasPermission['update:context1'] ||
>>>> hasPermission['update:context2']) &&
>>>> hasPermission['update:context3']}" type="Boolean"/>
>>>>
>>>> or something like that. I'm still working out the details.
>>>>
>>>> -Adrian
>>>>
>>>> Andrew Zeneski wrote:
>>>>> That sounds cool. I'm not sure what that would really look like,
>>>>> but nevertheless sounds really cool! :) If you need anything from
>>>>> me let me know...
>>>>> Andrew
>>>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>>>> Andrew Zeneski wrote:
>>>>>>> I'd be happy to discuss additional changes as well (which aren't
>>>>>>> yet documented) like adding support to check multiple permissions
>>>>>>> at once, returning a Map of results from that permission check.
>>>>>>> So, if you or anyone else has a wish list for security, let me
>>>>>>> know so I can get it all incorporated at the same time.
>>>>>>
>>>>>> Btw, I'm working on adding an extension to the UEL that will allow
>>>>>> permission expressions.
>>>>>>
>>>>>>
>>>>>> -Adrian
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I know this, but couldn't we replace them before calling the UEL
processor?
Jacopo
On Apr 30, 2009, at 7:43 PM, Adrian Crum wrote:
> Those keywords are not recognized by UEL.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> Adrian,
>> this is really interesting.
>> However I think it is time to start thinking to define our own xml
>> friendly keywords for && and || operators; I would like to express
>> that statement with something like this:
>> <set field="hasPermission" value="$
>> {(hasPermission['update:context1'] OR
>> hasPermission['update:context2']) AND
>> hasPermission['update:context3']}" type="Boolean"/>
>> Jacopo
>> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>>> <set field="hasPermission" value="$
>>> {(hasPermission['update:context1'] ||
>>> hasPermission['update:context2']) &&
>>> hasPermission['update:context3']}" type="Boolean"/>
>>>
>>> or something like that. I'm still working out the details.
>>>
>>> -Adrian
>>>
>>> Andrew Zeneski wrote:
>>>> That sounds cool. I'm not sure what that would really look like,
>>>> but nevertheless sounds really cool! :) If you need anything from
>>>> me let me know...
>>>> Andrew
>>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>>> Andrew Zeneski wrote:
>>>>>> I'd be happy to discuss additional changes as well (which
>>>>>> aren't yet documented) like adding support to check multiple
>>>>>> permissions at once, returning a Map of results from that
>>>>>> permission check. So, if you or anyone else has a wish list for
>>>>>> security, let me know so I can get it all incorporated at the
>>>>>> same time.
>>>>>
>>>>> Btw, I'm working on adding an extension to the UEL that will
>>>>> allow permission expressions.
>>>>>
>>>>>
>>>>> -Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
Those keywords are not recognized by UEL.
-Adrian
Jacopo Cappellato wrote:
> Adrian,
>
> this is really interesting.
> However I think it is time to start thinking to define our own xml
> friendly keywords for && and || operators; I would like to express that
> statement with something like this:
>
> <set field="hasPermission" value="${(hasPermission['update:context1'] OR
> hasPermission['update:context2']) AND hasPermission['update:context3']}"
> type="Boolean"/>
>
> Jacopo
>
>
> On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
>
>> <set field="hasPermission" value="${(hasPermission['update:context1']
>> || hasPermission['update:context2']) &&
>> hasPermission['update:context3']}" type="Boolean"/>
>>
>> or something like that. I'm still working out the details.
>>
>> -Adrian
>>
>> Andrew Zeneski wrote:
>>> That sounds cool. I'm not sure what that would really look like, but
>>> nevertheless sounds really cool! :) If you need anything from me let
>>> me know...
>>> Andrew
>>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>>> Andrew Zeneski wrote:
>>>>> I'd be happy to discuss additional changes as well (which aren't
>>>>> yet documented) like adding support to check multiple permissions
>>>>> at once, returning a Map of results from that permission check. So,
>>>>> if you or anyone else has a wish list for security, let me know so
>>>>> I can get it all incorporated at the same time.
>>>>
>>>> Btw, I'm working on adding an extension to the UEL that will allow
>>>> permission expressions.
>>>>
>>>>
>>>> -Adrian
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian,
this is really interesting.
However I think it is time to start thinking to define our own xml
friendly keywords for && and || operators; I would like to express
that statement with something like this:
<set field="hasPermission" value="${(hasPermission['update:context1']
OR hasPermission['update:context2']) AND
hasPermission['update:context3']}" type="Boolean"/>
Jacopo
On Apr 30, 2009, at 7:20 PM, Adrian Crum wrote:
> <set field="hasPermission" value="$
> {(hasPermission['update:context1'] ||
> hasPermission['update:context2']) &&
> hasPermission['update:context3']}" type="Boolean"/>
>
> or something like that. I'm still working out the details.
>
> -Adrian
>
> Andrew Zeneski wrote:
>> That sounds cool. I'm not sure what that would really look like,
>> but nevertheless sounds really cool! :) If you need anything from
>> me let me know...
>> Andrew
>> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>>> Andrew Zeneski wrote:
>>>> I'd be happy to discuss additional changes as well (which aren't
>>>> yet documented) like adding support to check multiple permissions
>>>> at once, returning a Map of results from that permission check.
>>>> So, if you or anyone else has a wish list for security, let me
>>>> know so I can get it all incorporated at the same time.
>>>
>>> Btw, I'm working on adding an extension to the UEL that will allow
>>> permission expressions.
>>>
>>>
>>> -Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
<set field="hasPermission" value="${(hasPermission['update:context1'] ||
hasPermission['update:context2']) &&
hasPermission['update:context3']}" type="Boolean"/>
or something like that. I'm still working out the details.
-Adrian
Andrew Zeneski wrote:
> That sounds cool. I'm not sure what that would really look like, but
> nevertheless sounds really cool! :) If you need anything from me let me
> know...
>
> Andrew
>
> On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
>
>> Andrew Zeneski wrote:
>>> I'd be happy to discuss additional changes as well (which aren't yet
>>> documented) like adding support to check multiple permissions at
>>> once, returning a Map of results from that permission check. So, if
>>> you or anyone else has a wish list for security, let me know so I can
>>> get it all incorporated at the same time.
>>
>> Btw, I'm working on adding an extension to the UEL that will allow
>> permission expressions.
>>
>>
>> -Adrian
>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
That sounds cool. I'm not sure what that would really look like, but
nevertheless sounds really cool! :) If you need anything from me let
me know...
Andrew
On Apr 30, 2009, at 1:00 PM, Adrian Crum wrote:
> Andrew Zeneski wrote:
>> I'd be happy to discuss additional changes as well (which aren't
>> yet documented) like adding support to check multiple permissions
>> at once, returning a Map of results from that permission check. So,
>> if you or anyone else has a wish list for security, let me know so
>> I can get it all incorporated at the same time.
>
> Btw, I'm working on adding an extension to the UEL that will allow
> permission expressions.
>
>
> -Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
Andrew Zeneski wrote:
> I'd be happy to discuss additional changes as well (which aren't yet
> documented) like adding support to check multiple permissions at once,
> returning a Map of results from that permission check. So, if you or
> anyone else has a wish list for security, let me know so I can get it
> all incorporated at the same time.
Btw, I'm working on adding an extension to the UEL that will allow
permission expressions.
-Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Apr 30, 2009, at 11:38 PM, David E Jones wrote:
>
> On Apr 30, 2009, at 11:07 AM, Jacopo Cappellato wrote:
>
>>
>> On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
>>
>>> ... I'd be happy to discuss additional changes as well (which
>>> aren't yet documented) like adding support to check multiple
>>> permissions at once, returning a Map of results from that
>>> permission check. So, if you or anyone else has a wish list for
>>> security, let me know so I can get it all incorporated at the same
>>> time.
>>>
>>> Andrew
>>
>> this is probably off topic here, but an enhancement I would like to
>> see in the form widgets is the ability for the widget model/
>> renderer to automatically select the proper field type according to
>> the permissions of the user: this is something that can be already
>> done using some scriptlets and the use-when attributes but it is
>> pretty complex.
>> I don't have a clear idea at the moment but the first options that
>> I can think of are:
>> 1) a new field type "display-update": it will be "display" if the
>> user has view permissions; it will be "update" if the user has
>> write permissions
>> 2) add, a required-permission attribute to the field element: this
>> will act as the use-when permission; or maybe adding something like
>> use-when="${ofbiz:hasPermission(UPDATE)}"
>> 3) submit buttons will be disabled if the user doesn't have proper
>> permissions
>> 4) base/default permissions could be set as an attribute in the
>> form element or derived from the service (if auto-fields is used)
>
> How would we handle the "redundant" permission problem?
This is a good point.
Probably #4 in my wish list would be closer to that: we could get the
permission service associated to the service specified by the "auto-
field" service and use it to derive the permissions for the form.
We may want to refactor the permission services to return the list of
permissions for a given action instead of just a boolean (or in
addition to it).
For example: the permission service, instead of answering the question:
"does the user X has UPDATE permission for the QUOTE action?"
could be refactored to answer the question:
"what are the permissions that user X has for the QUOTE process?"
if I have a form associated to the updateQuote service, but the user
has only READ permission for the QUOTE process, then the service will
return a permission error when called by the user, and the form will
render as a display form, without a submit button (or with a disabled
one).
Jacopo
>
>
> In other words, it is nice to check permissions on the client side
> and/or show permission impact in the UI, but that just improves the
> UI... it doesn't actually enforce any of those permissions checks
> because it is really easy to change HTML and/or spoof a request (ie
> users with valid credentials that can do other things could then get
> around permissions that are only checked in the UI). Because of this
> it is still necessary to check all permissions in services
> processing incoming data, otherwise we have a security hole that is
> pretty easy to exploit (well, if people realize it is there anyway).
>
> The trick is how do we setup permissions so that we set them up once
> and they function in both places (ie in the input processing for the
> actual security, and in the UI for user convenience)?
>
> -David
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David E Jones <da...@hotwaxmedia.com>.
I don't think it is common that permissions checked in the UI are
different than permissions checked when the input from the UI is
processed. In fact, I don't think I've ever run into that problem.
The problem I have run into over and over is that in almost every
toolkit and framework around (with just a few exceptions) you have to
configure or code the permission checks twice, and they often get
accidently out of sync (causing either usability problems or security
vulnerabilities).
If we're going to talk about extensions to the form widget or other
things for security purposes, I think we should talk about this
redundancy problem because it IS an issue for the framework and one
that people talk about when comparing the OFBiz framework to certain
competing modern frameworks...
-David
On Apr 30, 2009, at 4:42 PM, Adrian Crum wrote:
> No, I'm not saying I disagree with you. You totally missed my point.
> I don't think anyone is suggesting removing permissions checking
> from the UI or the services. Let's get that settled right away.
>
> Jacopo is asking for a way to control the display of screen widgets
> based on the user's permissions. You said: "The trick is how do we
> setup permissions so that we set them up once and they function in
> both places?" Maybe I'm misunderstanding your question. It sounds to
> me like you're suggesting a single method could be used in both
> scenarios, so I responded that the requirements are different - so a
> single method wouldn't work.
>
> We're already using permissions to control the UI - and they are the
> same ones used in the service calls. The problem is, it's hard to
> implement. I believe all that's being suggested here is some new
> widget attributes or something to make it easier.
>
> -Adrian
>
> David E Jones wrote:
>> On Apr 30, 2009, at 4:09 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> In other words, it is nice to check permissions on the client
>>>> side and/or show permission impact in the UI, but that just
>>>> improves the UI... it doesn't actually enforce any of those
>>>> permissions checks because it is really easy to change HTML and/
>>>> or spoof a request (ie users with valid credentials that can do
>>>> other things could then get around permissions that are only
>>>> checked in the UI).
>>>
>>> I think Jacopo's interest is an improved UI. Why render a Create
>>> New button when the user doesn't have the permission to create
>>> anything?
>> Yeah, that's what I said... ie with phrases like "that just
>> improves the UI" and "in the UI for user convenience".
>>>> The trick is how do we setup permissions so that we set them up
>>>> once and they function in both places (ie in the input processing
>>>> for the actual security, and in the UI for user convenience)?
>>>
>>> Is that even possible? The UI might contain multiple paths to
>>> follow, with each path requiring a different permission. Service
>>> invocations are generally a single path with a single permission.
>>>
>>> In other words, the UI might need to know the user's create,
>>> update, and delete permissions in order to render the screen, but
>>> the user action will result in only one service invocation - which
>>> requires only one of those user permissions.
>>>
>>> I thought about this a while back, and toyed with the idea of
>>> making the screen widgets permissions-aware.
>> So, are you saying that you disagree with what I wrote about the
>> purposes of permissions in different places, ie:
>> 1. input processing: for security
>> 2. UI artifacts: for user convenience (improved UI)
>> Maybe what I wrote wasn't clear enough, so I'll say it again:
>> permission checking in the UI is USELESS for security, it only
>> helps for an improved user experience.
>> I would even go so far as to assert that if anyone doesn't
>> understand this then they don't understand how web-based
>> applications work, and the applications they write will be full of
>> security holes.
>> This is why in OFBiz we REQUIRE security for services (or other
>> input processing logic) and it is OPTIONAL in the UI.
>> -David
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
No, I'm not saying I disagree with you. You totally missed my point. I
don't think anyone is suggesting removing permissions checking from the
UI or the services. Let's get that settled right away.
Jacopo is asking for a way to control the display of screen widgets
based on the user's permissions. You said: "The trick is how do we setup
permissions so that we set them up once and they function in both
places?" Maybe I'm misunderstanding your question. It sounds to me like
you're suggesting a single method could be used in both scenarios, so I
responded that the requirements are different - so a single method
wouldn't work.
We're already using permissions to control the UI - and they are the
same ones used in the service calls. The problem is, it's hard to
implement. I believe all that's being suggested here is some new widget
attributes or something to make it easier.
-Adrian
David E Jones wrote:
>
> On Apr 30, 2009, at 4:09 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> In other words, it is nice to check permissions on the client side
>>> and/or show permission impact in the UI, but that just improves the
>>> UI... it doesn't actually enforce any of those permissions checks
>>> because it is really easy to change HTML and/or spoof a request (ie
>>> users with valid credentials that can do other things could then get
>>> around permissions that are only checked in the UI).
>>
>> I think Jacopo's interest is an improved UI. Why render a Create New
>> button when the user doesn't have the permission to create anything?
>
> Yeah, that's what I said... ie with phrases like "that just improves the
> UI" and "in the UI for user convenience".
>
>>> The trick is how do we setup permissions so that we set them up once
>>> and they function in both places (ie in the input processing for the
>>> actual security, and in the UI for user convenience)?
>>
>> Is that even possible? The UI might contain multiple paths to follow,
>> with each path requiring a different permission. Service invocations
>> are generally a single path with a single permission.
>>
>> In other words, the UI might need to know the user's create, update,
>> and delete permissions in order to render the screen, but the user
>> action will result in only one service invocation - which requires
>> only one of those user permissions.
>>
>> I thought about this a while back, and toyed with the idea of making
>> the screen widgets permissions-aware.
>
> So, are you saying that you disagree with what I wrote about the
> purposes of permissions in different places, ie:
>
> 1. input processing: for security
> 2. UI artifacts: for user convenience (improved UI)
>
> Maybe what I wrote wasn't clear enough, so I'll say it again: permission
> checking in the UI is USELESS for security, it only helps for an
> improved user experience.
>
> I would even go so far as to assert that if anyone doesn't understand
> this then they don't understand how web-based applications work, and the
> applications they write will be full of security holes.
>
> This is why in OFBiz we REQUIRE security for services (or other input
> processing logic) and it is OPTIONAL in the UI.
>
> -David
>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David E Jones <da...@hotwaxmedia.com>.
On Apr 30, 2009, at 4:09 PM, Adrian Crum wrote:
> David E Jones wrote:
>> In other words, it is nice to check permissions on the client side
>> and/or show permission impact in the UI, but that just improves the
>> UI... it doesn't actually enforce any of those permissions checks
>> because it is really easy to change HTML and/or spoof a request (ie
>> users with valid credentials that can do other things could then
>> get around permissions that are only checked in the UI).
>
> I think Jacopo's interest is an improved UI. Why render a Create New
> button when the user doesn't have the permission to create anything?
Yeah, that's what I said... ie with phrases like "that just improves
the UI" and "in the UI for user convenience".
>> The trick is how do we setup permissions so that we set them up
>> once and they function in both places (ie in the input processing
>> for the actual security, and in the UI for user convenience)?
>
> Is that even possible? The UI might contain multiple paths to
> follow, with each path requiring a different permission. Service
> invocations are generally a single path with a single permission.
>
> In other words, the UI might need to know the user's create, update,
> and delete permissions in order to render the screen, but the user
> action will result in only one service invocation - which requires
> only one of those user permissions.
>
> I thought about this a while back, and toyed with the idea of making
> the screen widgets permissions-aware.
So, are you saying that you disagree with what I wrote about the
purposes of permissions in different places, ie:
1. input processing: for security
2. UI artifacts: for user convenience (improved UI)
Maybe what I wrote wasn't clear enough, so I'll say it again:
permission checking in the UI is USELESS for security, it only helps
for an improved user experience.
I would even go so far as to assert that if anyone doesn't understand
this then they don't understand how web-based applications work, and
the applications they write will be full of security holes.
This is why in OFBiz we REQUIRE security for services (or other input
processing logic) and it is OPTIONAL in the UI.
-David
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> In other words, it is nice to check permissions on the client side
> and/or show permission impact in the UI, but that just improves the
> UI... it doesn't actually enforce any of those permissions checks
> because it is really easy to change HTML and/or spoof a request (ie
> users with valid credentials that can do other things could then get
> around permissions that are only checked in the UI).
I think Jacopo's interest is an improved UI. Why render a Create New
button when the user doesn't have the permission to create anything?
> The trick is how do we setup permissions so that we set them up once and
> they function in both places (ie in the input processing for the actual
> security, and in the UI for user convenience)?
Is that even possible? The UI might contain multiple paths to follow,
with each path requiring a different permission. Service invocations are
generally a single path with a single permission.
In other words, the UI might need to know the user's create, update, and
delete permissions in order to render the screen, but the user action
will result in only one service invocation - which requires only one of
those user permissions.
I thought about this a while back, and toyed with the idea of making the
screen widgets permissions-aware.
-Adrian
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David E Jones <da...@hotwaxmedia.com>.
On Apr 30, 2009, at 11:07 AM, Jacopo Cappellato wrote:
>
> On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
>
>> ... I'd be happy to discuss additional changes as well (which
>> aren't yet documented) like adding support to check multiple
>> permissions at once, returning a Map of results from that
>> permission check. So, if you or anyone else has a wish list for
>> security, let me know so I can get it all incorporated at the same
>> time.
>>
>> Andrew
>
> this is probably off topic here, but an enhancement I would like to
> see in the form widgets is the ability for the widget model/renderer
> to automatically select the proper field type according to the
> permissions of the user: this is something that can be already done
> using some scriptlets and the use-when attributes but it is pretty
> complex.
> I don't have a clear idea at the moment but the first options that I
> can think of are:
> 1) a new field type "display-update": it will be "display" if the
> user has view permissions; it will be "update" if the user has write
> permissions
> 2) add, a required-permission attribute to the field element: this
> will act as the use-when permission; or maybe adding something like
> use-when="${ofbiz:hasPermission(UPDATE)}"
> 3) submit buttons will be disabled if the user doesn't have proper
> permissions
> 4) base/default permissions could be set as an attribute in the form
> element or derived from the service (if auto-fields is used)
How would we handle the "redundant" permission problem?
In other words, it is nice to check permissions on the client side and/
or show permission impact in the UI, but that just improves the UI...
it doesn't actually enforce any of those permissions checks because it
is really easy to change HTML and/or spoof a request (ie users with
valid credentials that can do other things could then get around
permissions that are only checked in the UI). Because of this it is
still necessary to check all permissions in services processing
incoming data, otherwise we have a security hole that is pretty easy
to exploit (well, if people realize it is there anyway).
The trick is how do we setup permissions so that we set them up once
and they function in both places (ie in the input processing for the
actual security, and in the UI for user convenience)?
-David
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I think this is a great idea and would be very useful. Could you
create a JIRA issue for this and relate it to OFBIZ-2380?
Andrew
On Apr 30, 2009, at 1:07 PM, Jacopo Cappellato wrote:
>
> On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
>
>> ... I'd be happy to discuss additional changes as well (which
>> aren't yet documented) like adding support to check multiple
>> permissions at once, returning a Map of results from that
>> permission check. So, if you or anyone else has a wish list for
>> security, let me know so I can get it all incorporated at the same
>> time.
>>
>> Andrew
>
> this is probably off topic here, but an enhancement I would like to
> see in the form widgets is the ability for the widget model/renderer
> to automatically select the proper field type according to the
> permissions of the user: this is something that can be already done
> using some scriptlets and the use-when attributes but it is pretty
> complex.
> I don't have a clear idea at the moment but the first options that I
> can think of are:
> 1) a new field type "display-update": it will be "display" if the
> user has view permissions; it will be "update" if the user has write
> permissions
> 2) add, a required-permission attribute to the field element: this
> will act as the use-when permission; or maybe adding something like
> use-when="${ofbiz:hasPermission(UPDATE)}"
> 3) submit buttons will be disabled if the user doesn't have proper
> permissions
> 4) base/default permissions could be set as an attribute in the form
> element or derived from the service (if auto-fields is used)
>
> Just my two cents
>
> Jacopo
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Apr 30, 2009, at 6:50 PM, Andrew Zeneski wrote:
> ... I'd be happy to discuss additional changes as well (which aren't
> yet documented) like adding support to check multiple permissions at
> once, returning a Map of results from that permission check. So, if
> you or anyone else has a wish list for security, let me know so I
> can get it all incorporated at the same time.
>
> Andrew
this is probably off topic here, but an enhancement I would like to
see in the form widgets is the ability for the widget model/renderer
to automatically select the proper field type according to the
permissions of the user: this is something that can be already done
using some scriptlets and the use-when attributes but it is pretty
complex.
I don't have a clear idea at the moment but the first options that I
can think of are:
1) a new field type "display-update": it will be "display" if the user
has view permissions; it will be "update" if the user has write
permissions
2) add, a required-permission attribute to the field element: this
will act as the use-when permission; or maybe adding something like
use-when="${ofbiz:hasPermission(UPDATE)}"
3) submit buttons will be disabled if the user doesn't have proper
permissions
4) base/default permissions could be set as an attribute in the form
element or derived from the service (if auto-fields is used)
Just my two cents
Jacopo
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Inline...
On Apr 30, 2009, at 12:11 PM, David E Jones wrote:
>
> What is the point of changing all of the security data like this? In
> other words, is there some reason that the new security stuff can't
> use the same permissions syntax/convention as the older security
> stuff?
>
Looks like you probably missed the big design document which explains
everything:
http://docs.ofbiz.org/x/-B0
http://docs.ofbiz.org/x/JR4
> The thing to keep in mind is that not only will there be a big
> effort to make all of these changes in OFBiz, but everyone with
> production data will have to perform a big non-backward-compatible
> database migration that will require system downtime.
Yes, it will be a big effort, but it is something I plan to tackle as
quickly as possible. As for non-backward-compatible database changes,
I totally disagree. As long as the new seed data is loaded, nothing
else is required (except some minor DB schema changes, all adds, no
deletes) I was very careful when designing this to avoid this
completely. There is no reason why old permission data and new
permission data cannot live together in the database. It will hurt
nothing.
Also, it should be fairly easy to write a simple migration script to
remove the old permissions; but that could get tricky when there are
custom applications or code which doesn't get migrated in this effort.
>
> It is certainly okay to require that if there is a good reason for
> it, but I guess that's what I'm not seeing here... the benefits we
> all get from the new format...
Instead of me explaining this over and over (which is what I figured
would happen) I put everything together in a document in confluence
and linked that to all the JIRA issues. My guess is after you read
that doc, you will completely understand the importance of the
permission format changes which is really what prompted the entire
effort.
I'd be happy to discuss additional changes as well (which aren't yet
documented) like adding support to check multiple permissions at once,
returning a Map of results from that permission check. So, if you or
anyone else has a wish list for security, let me know so I can get it
all incorporated at the same time.
Andrew
Re:New Security system considerations
Posted by BJ Freeman <bj...@free-man.net>.
at this point I am neither for or against the new proposal.
after I get it under my belt I will offer my view.
However I do want to add more to the Access portion.
I would like to consider extending granularity of the permission to
include Menus and display of data.
the focus is that some menus should not be active till other processes
are accomplished. This include logging in, completing needed
information, like account information, or website.
Though this could be argued that it is not a security function, at
certain levels it is.
The menu activation could also be controlled by a entity similar to
validstatus change, but that is a different discussion.
>
> I'd be happy to discuss additional changes as well (which aren't yet
> documented) like adding support to check multiple permissions at once,
> returning a Map of results from that permission check. So, if you or
> anyone else has a wish list for security, let me know so I can get it
> all incorporated at the same time.
>
> Andrew
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David E Jones <jo...@apache.org>.
What is the point of changing all of the security data like this? In
other words, is there some reason that the new security stuff can't
use the same permissions syntax/convention as the older security stuff?
The thing to keep in mind is that not only will there be a big effort
to make all of these changes in OFBiz, but everyone with production
data will have to perform a big non-backward-compatible database
migration that will require system downtime.
It is certainly okay to require that if there is a good reason for it,
but I guess that's what I'm not seeing here... the benefits we all get
from the new format...
-David
On Apr 30, 2009, at 12:23 AM, jaz@apache.org wrote:
> Author: jaz
> Date: Thu Apr 30 06:23:18 2009
> New Revision: 770084
>
> URL: http://svn.apache.org/viewvc?rev=770084&view=rev
> Log:
> Refactored Example Application to use new security mechanics - JIRA
> OFBIZ-2392
>
> Added:
> ofbiz/trunk/framework/example/security/
> ofbiz/trunk/framework/example/security/CreateExample.groovy
> ofbiz/trunk/framework/example/security/UpdateExample.groovy
> Modified:
> ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> ofbiz/trunk/framework/example/entitydef/entitymodel.xml
> ofbiz/trunk/framework/example/ofbiz-component.xml
> ofbiz/trunk/framework/example/servicedef/services.xml
> ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml
> ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml
> ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml
>
> Modified: ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/config/ExampleUiLabels.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> (original)
> +++ ofbiz/trunk/framework/example/config/ExampleUiLabels.xml Thu Apr
> 30 06:23:18 2009
> @@ -466,13 +466,13 @@
> <value xml:lang="it">DA FARE</value>
> </property>
> <property key="ExampleViewPermissionError">
> - <value xml:lang="en">You do not have permission to view
> this page. ("EXAMPLE_VIEW" or "EXAMPLE_ADMIN" needed)</value>
> - <value xml:lang="fr">Vous n'avez pas l'autorisation de voir
> cette page ("EXAMPLE_VIEW" ou "EXAMPLE_ADMIN" nécessaire)</value>
> - <value xml:lang="it">Tu non sei autorizzare a vedere questa
> pagina. (Permesso "EXAMPLE_VIEW" o "EXAMPLE_ADMIN" necessario)</value>
> - <value xml:lang="ro">Nu esti autorizat sa vezi aceasta
> pagina. (Este necesar Permisul "EXAMPLE_VIEW" sau "EXAMPLE_ADMIN")</
> value>
> - <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав длÑ
> пÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
> Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "EXAMPLE_VIEW" или "EXAMPLE_ADMIN")</value>
> - <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸
> à
> ¸
>
> à
> ¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹
> (หà¸à¹à¸² "EXAMPLE_VIEW" หรืภ"EXAMPLE_ADMIN"
> à¸à¸µà¹à¸à¹à¸ à¸à¸à¸²à¸£)</value>
> - <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé
> ¢çæéã(éè¦"EXAMPLE_VIEW"æ"EXAMPLE_ADMIN")</value>
> + <value xml:lang="en">You do not have permission to view
> this page. ("access:example" needed)</value>
> + <value xml:lang="fr">Vous n'avez pas l'autorisation de voir
> cette page ("access:example" nécessaire)</value>
> + <value xml:lang="it">Tu non sei autorizzare a vedere questa
> pagina. (Permesso "access:example" necessario)</value>
> + <value xml:lang="ro">Nu esti autorizat sa vezi aceasta
> pagina. (Este necesar Permisul "access:example")</value>
> + <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав длÑ
> пÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
> Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "access:example")</value>
> + <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸
> à
> ¸
>
> à
> ¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹
> (หà¸à¹à¸² "access:example" à¸à¸µà¹à¸à¹à¸ à¸à¸à¸²à¸£)</value>
> + <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé
> ¢çæéã(éè¦"access:example")</value>
> </property>
> <property key="ExampleWelcome">
> <value xml:lang="en">Welcome to the Example application!</
> value>
>
> Modified: ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/data/ExampleSecurityData.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> (original)
> +++ ofbiz/trunk/framework/example/data/ExampleSecurityData.xml Thu
> Apr 30 06:23:18 2009
> @@ -19,16 +19,30 @@
> -->
> <entity-engine-xml>
> <!-- Example security -->
> - <SecurityPermission description="View operations in the Example
> Management Screens." permissionId="EXAMPLE_VIEW"/>
> - <SecurityPermission description="Create operations in the
> Example Management Screens." permissionId="EXAMPLE_CREATE"/>
> - <SecurityPermission description="Update operations in the
> Example Management Screens." permissionId="EXAMPLE_UPDATE"/>
> - <SecurityPermission description="Delete operations in the
> Example Management Screens." permissionId="EXAMPLE_DELETE"/>
> - <SecurityPermission description="ALL operations in the Example
> Management Screens." permissionId="EXAMPLE_ADMIN"/>
> - <SecurityGroupPermission groupId="FULLADMIN"
> permissionId="EXAMPLE_ADMIN"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_CREATE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_DELETE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_UPDATE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_VIEW"/>
> - <SecurityGroupPermission groupId="VIEWADMIN"
> permissionId="EXAMPLE_VIEW"/>
> - <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="EXAMPLE_ADMIN"/>
> + <SecurityPermission description="ACCESS the Example
> Application" permissionId="access:example"/>
> + <SecurityPermission description="CREATE operations in the
> Example Application" permissionId="create:example"
> dynamicAccess="component://example/security/CreateExample.groovy"/>
> + <SecurityPermission description="READ operations in the Example
> Application" permissionId="read:example"/>
> + <SecurityPermission description="UPDATE operations in the
> Example Application" permissionId="update:example"
> dynamicAccess="component://example/security/UpdateExample.groovy"/>
> + <SecurityPermission description="DELETE operations in the
> Example Application" permissionId="delete:example"/>
> +
> + <SecurityPermission description="CREATE STATUS operations in
> the Example Application" permissionId="create:example:status"/>
> + <SecurityPermission description="READ STATUS operations in the
> Example Application" permissionId="read:example:status"/>
> + <SecurityPermission description="UPDATE STATUS operations in
> the Example Application" permissionId="update:example:status"/>
> + <SecurityPermission description="DELETE STATUS operations in
> the Example Application" permissionId="delete:example:status"/>
> +
> + <SecurityPermission description="CREATE ITEM operations in the
> Example Application" permissionId="create:example:item"/>
> + <SecurityPermission description="READ ITEM operations in the
> Example Application" permissionId="read:example:item"/>
> + <SecurityPermission description="UPDATE ITEM operations in the
> Example Application" permissionId="update:example:item"/>
> + <SecurityPermission description="DELETE ITEM operations in the
> Example Application" permissionId="delete:example:item"/>
> +
> + <SecurityPermission description="CREATE FEATURE operations in
> the Example Application" permissionId="create:example:feature"/>
> + <SecurityPermission description="READ ITEM operations in the
> Example Application" permissionId="read:example:feature"/>
> + <SecurityPermission description="UPDATE ITEM operations in the
> Example Application" permissionId="update:example:feature"/>
> + <SecurityPermission description="DELETE ITEM operations in the
> Example Application" permissionId="delete:example:feature"/>
> +
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="access:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="create:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="read:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="update:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="delete:example"/>
> </entity-engine-xml>
>
> Modified: ofbiz/trunk/framework/example/entitydef/entitymodel.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/entitydef/entitymodel.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/entitydef/entitymodel.xml (original)
> +++ ofbiz/trunk/framework/example/entitydef/entitymodel.xml Thu Apr
> 30 06:23:18 2009
> @@ -55,6 +55,7 @@
> <field name="exampleDate" type="date-time"></field>
> <field name="anotherDate" type="date-time"></field>
> <field name="anotherText" type="long-varchar"></field>
> + <field name="createdByUser" type="id-vlong-ne"></field>
> <prim-key field="exampleId"/>
> <relation type="one" fk-name="EXMPL_TYP" rel-entity-
> name="ExampleType">
> <key-map field-name="exampleTypeId"/>
> @@ -62,6 +63,9 @@
> <relation type="one" fk-name="EXMPL_STTS" rel-entity-
> name="StatusItem">
> <key-map field-name="statusId"/>
> </relation>
> + <relation type="one" fk-name="EXMPL_USER" rel-entity-
> name="UserLogin">
> + <key-map field-name="createdByUser" rel-field-
> name="userLoginId"/>
> + </relation>
> </entity>
> <entity entity-name="ExampleItem" package-
> name="org.ofbiz.example.example" title="Example Item Entity" default-
> resource-name="ExampleEntityLabels">
> <field name="exampleId" type="id-ne"></field>
>
> Modified: ofbiz/trunk/framework/example/ofbiz-component.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/ofbiz-component.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/ofbiz-component.xml (original)
> +++ ofbiz/trunk/framework/example/ofbiz-component.xml Thu Apr 30
> 06:23:18 2009
> @@ -54,6 +54,6 @@
> menu-name="secondary"
> server="default-server"
> location="webapp/example"
> - base-permission="OFBTOOLS,EXAMPLE"
> + base-permission="access:example"
> mount-point="/example"/>
> </ofbiz-component>
>
> Added: ofbiz/trunk/framework/example/security/CreateExample.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/CreateExample.groovy?rev=770084&view=auto
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/security/CreateExample.groovy
> (added)
> +++ ofbiz/trunk/framework/example/security/CreateExample.groovy Thu
> Apr 30 06:23:18 2009
> @@ -0,0 +1,21 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> + // this dynamic access grants ANYONE access
> + return true;
> \ No newline at end of file
>
> Added: ofbiz/trunk/framework/example/security/UpdateExample.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/UpdateExample.groovy?rev=770084&view=auto
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/security/UpdateExample.groovy
> (added)
> +++ ofbiz/trunk/framework/example/security/UpdateExample.groovy Thu
> Apr 30 06:23:18 2009
> @@ -0,0 +1,34 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> +import org.ofbiz.base.util.Debug;
> +
> +exampleId = permissionContext.get("exampleId");
> +Debug.logInfo("Groovy DA Context : " + permissionContext, "groovy");
> +Debug.logInfo("Calling UpdateExample.groovy - " + exampleId,
> "groovy");
> +if (exampleId != null) {
> + example = delegator.findOne("Example", [exampleId : exampleId],
> true);
> + Debug.logInfo("Example : " + example, "groovy");
> +
> + if (example.createdByUser == null ||
> userId.equals(example.createdByUser)) {
> + return true;
> + }
> +}
> +
> +return false;
>
> Modified: ofbiz/trunk/framework/example/servicedef/services.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/servicedef/services.xml (original)
> +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30
> 06:23:18 2009
> @@ -27,29 +27,37 @@
> <!-- Example & Related Services -->
> <service name="createExample" default-entity-name="Example"
> engine="entity-auto" invoke="create" auth="true">
> <description>Create a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleTypeId" optional="false"/>
> <override name="statusId" optional="false"/>
> - <override name="exampleName" optional="false"/>
> + <override name="exampleName" optional="false"/>
> </service>
> <service name="updateExample" default-entity-name="Example"
> engine="entity-auto" invoke="update" auth="true">
> <description>Update a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <attribute name="oldStatusId" type="String" mode="OUT"
> optional="false"/>
> </service>
> <service name="deleteExample" default-entity-name="Example"
> engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
> <service name="createExampleStatus" default-entity-
> name="ExampleStatus" engine="simple"
> location="component://example/script/org/ofbiz/example/
> example/ExampleServices.xml" invoke="createExampleStatus" auth="true">
> <description>Create a ExampleStatus</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:status:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="all" mode="IN" optional="false">
> <exclude field-name="statusDate"/>
> <exclude field-name="statusEndDate"/>
> @@ -58,7 +66,9 @@
>
> <service name="createExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="create" auth="true">
> <description>Create a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleItemSeqId" mode="OUT"/> <!-- make
> this OUT rather than IN, we will automatically generate the next sub-
> sequence ID -->
> @@ -66,60 +76,78 @@
> </service>
> <service name="updateExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="update" auth="true">
> <description>Update a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- ExampleFeature Services -->
> <service name="createExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="create"
> auth="true">
> <description>Create a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="description" optional="false"/>
> </service>
> <service name="updateExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="update"
> auth="true">
> <description>Update a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="delete"
> auth="true">
> <description>Delete a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <service name="createExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="create"
> auth="true">
> <description>Create a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="fromDate" optional="true"/>
> </service>
> <service name="updateExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="update"
> auth="true">
> <description>Update a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="delete"
> auth="true">
> <description>Delete a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- Permission Services -->
> + <!-- @deprecated
> <service name="exampleGenericPermission" engine="simple"
> location="component://example/script/org/ofbiz/example/
> ExamplePermissionServices.xml" invoke="exampleGenericPermission">
> <implements service="permissionInterface"/>
> </service>
> + -->
>
> <!-- Example ServiceTest Service -->
> <service name="testCreateExampleService" engine="simple"
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> CommonScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/CommonScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> Thu Apr 30 06:23:18 2009
> @@ -71,7 +71,7 @@
> <section>
> <condition>
> <and>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> <not><if-empty field="example"/
> ></not>
> </and>
> </condition>
> @@ -82,9 +82,9 @@
> </decorator-section>
> <decorator-section name="body">
> <section>
> - <!-- do check for EXAMPLE, _VIEW
> permission -->
> + <!-- do check for access:example
> permission -->
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <section>
> @@ -135,7 +135,7 @@
> <section>
> <condition>
> <and>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> <not><if-empty
> field="exampleFeature"/></not>
> </and>
> </condition>
> @@ -148,7 +148,7 @@
> <section>
> <!-- do check for EXAMPLE, _VIEW
> permission -->
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <section>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <container style="h1"><label>$
> {uiLabelMap[titleProperty]}</label></container>
> @@ -68,7 +68,7 @@
> <screen name="ListExampleFormOnly">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <!-- NOTE: these are needed because this may be run
> as a top level screen and would have no decorator -->
> @@ -84,7 +84,7 @@
> <screen name="CreateExampleFormOnly">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <!-- these are only needed so that when bsh
> evaluates use-when attributes these will exist and not cause an
> error -->
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <decorator-screen
> name="FindScreenDecorator" location="component://common/widget/
> CommonScreens.xml">
> @@ -98,7 +98,7 @@
> <screen name="LookupExampleFeature">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <property-map resource="ExampleUiLabels" map-
> name="uiLabelMap" global="true"/>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleForms.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleForms.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> Thu Apr 30 06:23:18 2009
> @@ -142,6 +142,8 @@
> <field name="displayAnotherText" use-when="example!
> =null&&example.get("anotherText")!=null">
> <display description="${example.anotherText}"/>
> </field>
> + <field name="createdByUser" use-
> when="example==null"><hidden value="${userLogin.userLoginId}"/></
> field>
> + <field name="createdByUser" use-when="example!
> =null"><hidden/></field>
> <field name="submitButton" use-when="example==null" title="$
> {uiLabelMap.CommonCreate}"><submit button-type="button"/></field>
> <field name="submitButton" use-when="example!=null" title="$
> {uiLabelMap.CommonUpdate}"><submit button-type="button"/></field>
> </form>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <decorator-screen
> name="FindScreenDecorator" location="component://common/widget/
> CommonScreens.xml">
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml Thu Apr 30 06:23:18 2009
> @@ -31,7 +31,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <container style="h1"><label>$
> {uiLabelMap.PageTitleFormWidgetExamples}</label></container>
>
>
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
Look in the Asset Maintenance component.
-Adrian
Andrew Zeneski wrote:
> Adrian,
>
> I will start a new thread to discuss this, but before I do I want to
> make sure there isn't something I neglected to account for. Could you
> please provide an example of such a service which uses SECA permission
> services?
>
> Andrew
>
> On May 1, 2009, at 12:04 PM, Adrian Crum wrote:
>
>> Andrew,
>>
>> I thought we were getting away from using the <required-permissions>
>> element and using the <permission-service> element instead.
>>
>> If this type of change is made in other components, it will break a
>> lot of code - because some components use permission service SECAs.
>>
>> -Adrian
>>
>> jaz@apache.org wrote:
>>> Author: jaz
>>> Date: Thu Apr 30 06:23:18 2009
>>> New Revision: 770084
>>> URL: http://svn.apache.org/viewvc?rev=770084&view=rev
>>> Log:
>>> Refactored Example Application to use new security mechanics - JIRA
>>> OFBIZ-2392
>>
>> ...
>>
>>
>>> Modified: ofbiz/trunk/framework/example/servicedef/services.xml
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
>>>
>>> ==============================================================================
>>>
>>> --- ofbiz/trunk/framework/example/servicedef/services.xml (original)
>>> +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30
>>> 06:23:18 2009
>>> @@ -27,29 +27,37 @@
>>> <!-- Example & Related Services -->
>>> <service name="createExample" default-entity-name="Example"
>>> engine="entity-auto" invoke="create" auth="true">
>>> <description>Create a Example</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="CREATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission permission="create:example"/>
>>> + </required-permissions> <auto-attributes
>>> include="pk" mode="OUT" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> <override name="exampleTypeId" optional="false"/>
>>> <override name="statusId" optional="false"/>
>>> - <override name="exampleName" optional="false"/>
>>> + <override name="exampleName" optional="false"/>
>>> </service>
>>> <service name="updateExample" default-entity-name="Example"
>>> engine="entity-auto" invoke="update" auth="true">
>>> <description>Update a Example</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="UPDATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="update:example:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> <attribute name="oldStatusId" type="String" mode="OUT"
>>> optional="false"/>
>>> </service>
>>> <service name="deleteExample" default-entity-name="Example"
>>> engine="entity-auto" invoke="delete" auth="true">
>>> <description>Delete a Example</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="DELETE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="delete:example:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> </service>
>>> <service name="createExampleStatus"
>>> default-entity-name="ExampleStatus" engine="simple"
>>>
>>> location="component://example/script/org/ofbiz/example/example/ExampleServices.xml"
>>> invoke="createExampleStatus" auth="true">
>>> <description>Create a ExampleStatus</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="CREATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="update:example:status:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="all" mode="IN" optional="false">
>>> <exclude field-name="statusDate"/>
>>> <exclude field-name="statusEndDate"/>
>>> @@ -58,7 +66,9 @@
>>> <service name="createExampleItem"
>>> default-entity-name="ExampleItem" engine="entity-auto"
>>> invoke="create" auth="true">
>>> <description>Create a ExampleItem</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="CREATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="create:example:item:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> <override name="exampleItemSeqId" mode="OUT"/> <!-- make this
>>> OUT rather than IN, we will automatically generate the next
>>> sub-sequence ID -->
>>> @@ -66,60 +76,78 @@
>>> </service>
>>> <service name="updateExampleItem"
>>> default-entity-name="ExampleItem" engine="entity-auto"
>>> invoke="update" auth="true">
>>> <description>Update a ExampleItem</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="UPDATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="update:example:item:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> </service>
>>> <service name="deleteExampleItem"
>>> default-entity-name="ExampleItem" engine="entity-auto"
>>> invoke="delete" auth="true">
>>> <description>Delete a ExampleItem</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="DELETE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="delete:example:item:${exampleId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> </service>
>>> <!-- ExampleFeature Services -->
>>> <service name="createExampleFeature"
>>> default-entity-name="ExampleFeature" engine="entity-auto"
>>> invoke="create" auth="true">
>>> <description>Create a ExampleFeature</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="CREATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission permission="create:example:feature"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="OUT" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> <override name="description" optional="false"/>
>>> </service>
>>> <service name="updateExampleFeature"
>>> default-entity-name="ExampleFeature" engine="entity-auto"
>>> invoke="update" auth="true">
>>> <description>Update a ExampleFeature</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="UPDATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission permission="update:example:feature"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> </service>
>>> <service name="deleteExampleFeature"
>>> default-entity-name="ExampleFeature" engine="entity-auto"
>>> invoke="delete" auth="true">
>>> <description>Delete a ExampleFeature</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="DELETE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission permission="delete:example:feature"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> </service>
>>> <service name="createExampleFeatureAppl"
>>> default-entity-name="ExampleFeatureAppl" engine="entity-auto"
>>> invoke="create" auth="true">
>>> <description>Create a ExampleFeatureAppl</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="CREATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="create:example:feature:${exampleFeatureId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> <override name="fromDate" optional="true"/>
>>> </service>
>>> <service name="updateExampleFeatureAppl"
>>> default-entity-name="ExampleFeatureAppl" engine="entity-auto"
>>> invoke="update" auth="true">
>>> <description>Update a ExampleFeatureAppl</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="UPDATE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="update:example:feature:${exampleFeatureId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>> </service>
>>> <service name="deleteExampleFeatureAppl"
>>> default-entity-name="ExampleFeatureAppl" engine="entity-auto"
>>> invoke="delete" auth="true">
>>> <description>Delete a ExampleFeatureAppl</description>
>>> - <permission-service service-name="exampleGenericPermission"
>>> main-action="DELETE"/>
>>> + <required-permissions join-type="AND">
>>> + <check-permission
>>> permission="delete:example:feature:${exampleFeatureId}"/>
>>> + </required-permissions>
>>> <auto-attributes include="pk" mode="IN" optional="false"/>
>>> </service>
>>> <!-- Permission Services -->
>>> + <!-- @deprecated
>>> <service name="exampleGenericPermission" engine="simple"
>>>
>>> location="component://example/script/org/ofbiz/example/ExamplePermissionServices.xml"
>>> invoke="exampleGenericPermission">
>>> <implements service="permissionInterface"/>
>>> </service>
>>> + -->
>>> <!-- Example ServiceTest Service -->
>>> <service name="testCreateExampleService" engine="simple"
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 opens up doors for building tools that will make Ofbiz
Administrators life lot easy. Like now I can write tools that will
scan all the services/ forms/screen/menu widgets (may request entries
in controller) and present me a tree of
1) Artifacts like services, screens, forms. Resources that you will
like to secure.
2) List of different levels of permissions.
Artifact node will show permission needed and children nodes that are
list of users who have access the them.
Permission node can list users who have those permission and list of
artifacts that are allowed to use at that level.
Administrator will be able to add or remove user or change level of
access.
If done right permissions in special purpose applications will be much
more manageable. Auto-grant functionality can be {quote} extended
{quote}, we can connect it with date model that stores permission
dependency.
e.g When user is granted "update:sfa:contact:10000" permission, How
will security framework know that its same as "update:party:10000"? We
can setup data for mapping special purpose permissions with
fundamental permissions. So when security framework finds that called
service requires "update:party:10000" permission and user does not
have it then figure out if user have permissions that are equivalent
or better then "update:party:10000" permission.
Auto-grant concept can be extended for securing higher level
(compound) services that in turn call multiple services. Just an idea,
if we make our request secured like services, then we can secure our
UI components because they know request id.
>
> Also, I believe HWM is going to help by providing some resources to
> assist in the effort.
+1
Whatever we decide, I am happy we are thinking about it.
Regards
Anil Patel
On May 1, 2009, at 2:23 PM, Andrew Zeneski 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.
>
> While this is a really creative workaround for the limitations in
> the current security implementation, it is by no means an ideal
> solution. It is even more logic spread out in even more places
> making understanding and customizing authorization even more
> cumbersome.
>
> For these exact situations, the auto-grant functionality was
> implemented. So, instead of using ECAs to override permissions, you
> would define seed data (in the Asset Maint component, SFA, etc)
> which define which permissions are granted when a user is granted a
> specific application permission.
>
> There is a Use Case defined in the document (http://docs.ofbiz.org/x/-B0
> ) which explains how this would work for the SFA application.
>
> Just for the record, nothing will break. The two frameworks can live
> side by side during the migration process. It is my plan to knock
> this out as quickly as possible, one application at a time.
> Also, I believe HWM is going to help by providing some resources to
> assist in the effort.
>
+1
> Andrew
>
> On May 1, 2009, at 1:36 PM, Andrew Zeneski wrote:
>
>> 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 functionality, or tied to services
>> directly, the API should be the governor of all security. This
>> means no more writing security logic in the functionality, and no
>> more permission services attached directly to functionality
>> (services or ecas). This is a bad design IMHO because it spreads
>> the permission logic around in multiple places and makes it
>> impossible to get the same results when checking permissions from
>> different framework tools.
>>
>> -- We want to be consistent, and be able to obtain the same
>> information from the UI or screen/form as we would get from a
>> service call.
>> -- Main point of contact is the Authorization interface.
>>
>> 2. Permission services become Dynamic Access (DA). Now instead of
>> having permission services attached to services, we have Dynamic
>> Access implementations which can be a compiled Java object, a
>> Groovy script or a Service. My personal preference here is the
>> Groovy script, but the API current supports all three. This DA
>> logic is attached to a permission instead of a service.
>>
>> -- This allows for extending or changing the permission logic for a
>> specific implementation/customization/application much easier.
>> Since the DAs are all data driven, changing the seed data you can
>> change the logic which is used. This means you no longer have to
>> customize the services or logic in OFBiz to change the way
>> authorization is handled for your company (or client); one less
>> thing to worry about when merging customizations with the open
>> source project.
>>
>> -- for groovy use "component://path/to/script.groovy" in the
>> dynamicAccess field on SecurityPermission.
>> -- for services use "service:serviceName" in the dynamicAccess
>> field on SecurityPermission
>> -- for objects use "org.ofbiz.path.to.Object (which implements
>> DynamicAccess)" in the dynamicAccess field on SecurityPermission
>>
>> 3. Avoid having to check multiple permissions, for example
>> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission
>> format which embeds all permissions which will be accepted:
>>
>> Example: update:party:contact:10000 - Update the contact
>> information for party 10000
>>
>> This will allow anyone who has:
>> "update" or "update:party" or "update:party:contact" or is granted
>> record level access by the DA logic.
>>
>> 4. Define permission for users, not admins. Instead of looking for
>> a static permission, set the permission to be checked at the most
>> granular level. When doing so, admin users will always have
>> permission and the API will handle user access using DA logic.
>>
>> -- see: http://docs.ofbiz.org/x/JR4
>>
>> That's enough to get started, http://docs.ofbiz.org/x/-B0 contains
>> a lot more details; interested parties are encouraged to read it
>> through.
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by David E Jones <da...@hotwaxmedia.com>.
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 do :)
Yes, I agree... a discussion and feedback is a far better approach.
> This is VERY similar to the existing security implementation, and
> very similar to other security APIs out there (JSecurity, Spring
> Security, etc). The slight differences are:
>
> Easier to understand and follow. Reading the new permission string
> format, you can see what is being checked. Nothing is hidden. The
> logic used to determine granular access control it defined on the
> permission itself. No more guessing where permission logic is located.
Subjective benefit.
> It is much easier to extend, create seed data which overwrites the
> default permission logic references and use your own custom logic to
> determine access. No need to override service definitions or patch
> code (well once the migration is complete) or comment out ECAs.
Also a subjective benefit.
-David
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
The concerns were communicated and ignored, hence the Confluence page.
I'm not new to this process, and I'm not suggesting anything I haven't done myself.. When I have an idea, I present it to the dev mailing list and wait for responses. If there is some interest, I post POC code in Jira (just do a search on "Sandbox:" with me as the reporter). Others are able to comment and provide patches. When everyone agrees on the change, I commit it.
As far as community involvement in the new security framework is concerned, a simple check of timestamps will reveal:
April 24, Confluence page created: "OFBiz Security Refactor"
April 27, First mention of Security Refactor on ml: Jacques reply to "Best place for security check?"
April 28, Jira OFBIZ-2380 created: "Security Re-Implementation"
April 29, SVN commit 769928: "implementation of new authorization (authz) functionality"
I don't see a lot of community involvement there. Rather, I see a design being foisted on the community.
Unlike Andrew, when I have an idea, I present it to the community first - before I start "working hard on it." I have a lot of ideas - many of them not worth pursuing, and the community has been good at bringing that to my attention (the SAX widgets parsing idea is a recent example).
So, instead of going back and forth in this thread, why not create a new one - one that invites others to participate in the process. It's obvious from the conversation so far that some have felt excluded. So why object to starting over?
-Adrian
--- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@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 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 wait in vain for people to comment further.
>
> All this could easily have been avoided by interested
> parties simply commenting that they are actually interested
> and would like time to comment further instead of just
> assuming that the proposer is aware that you're going to
> get around to it at some point.
>
> Regards
> Scott
>
>
> On 2/05/2009, at 12:25 PM, Adrian Crum wrote:
>
> >
> > --- On Fri, 5/1/09, Scott Gray
> <sc...@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:
> >
> >
> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797
> >
> > -Adrian
> >
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 wait in vain for people
to comment further.
All this could easily have been avoided by interested parties simply
commenting that they are actually interested and would like time to
comment further instead of just assuming that the proposer is aware
that you're going to get around to it at some point.
Regards
Scott
On 2/05/2009, at 12:25 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Scott Gray <sc...@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:
>
> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Scott Gray <sc...@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:
http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model?focusedCommentId=7797#comment-7797
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Inline
On 2/05/2009, at 10:45 AM, Adrian Crum wrote:
>
> Don't get me wrong, I'm not resisting change. I commented on your
> design document that I'm in support of a security refactor. I'm sure
> others in the community would support that too.
>
> The problem is, this wasn't discussed with the community beforehand.
> No one was given an opportunity to provide input. It appears (and I
> know that this might not be true) that the design was created, some
> coding had been done, and THEN a document was drawn up and code
> committed shortly afterward.
Appearances must be deceiving, to the best of my knowledge Andrew put
a lot of effort into creating a proposal, posted it to confluence and
created a jira issue linking to the page (which got sent to the dev
list). He then responded to all the comments that people made, waited
a few days for additional comments and THEN began coding.
>
> My recommendation would be to reboot this entire process to give the
> community a chance to be involved in the design.
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.
>
> We should:
>
> 1. Send an email to the dev mailing list (and optionally the user
> list) asking for comments on the existing security framework and
> what they would like to see changed.
I agree this could have been done more explicitly but a jira issue was
created which does get sent to the dev list. People obviously saw it
because comments were posted to the page.
>
> 2. Compile the list into a set of design objectives.
>
> 3. Send the list to the dev mailing list and ask for suggestions for
> implementing the design objectives.
>
> 4. Compile a list of implementations and send it to the dev mailing
> list for a vote.
>
> From my perspective, that's how a developer community should work.
> Until those steps are followed, you're going to have a lot of people
> asking the same questions I am - because they weren't involved and
> don't understand what you're doing.
I don't understand why you don't understand, how is what has been
committed different from the detailed design proposal that Andrew
posted last week? I now realize you've obviously read it because you
commented on the page, so if you don't understand what is being done
now then you mustn't have understood it last week either and if you
didn't understand it last week why didn't you post more comments/
questions?
>
> -Adrian
>
>
>
> --- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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 tried to cover everything in the document, but
>> that's impossible to do :)
>>
>> This is VERY similar to the existing security
>> implementation, and very similar to other security APIs out
>> there (JSecurity, Spring Security, etc). The slight
>> differences are:
>>
>> Easier to understand and follow. Reading the new permission
>> string format, you can see what is being checked. Nothing is
>> hidden. The logic used to determine granular access control
>> it defined on the permission itself. No more guessing where
>> permission logic is located.
>>
>> It is much easier to extend, create seed data which
>> overwrites the default permission logic references and use
>> your own custom logic to determine access. No need to
>> override service definitions or patch code (well once the
>> migration is complete) or comment out ECAs.
>>
>> So, now my questions for you are: What is missing? What
>> does this new API NOT do, which you are looking for?
>>
>>
>> Andrew
>>
>>
>> On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
>>>
>>> I read the Auto-Grant section. The question is, where
>> is the seed data shown in your code example located? If
>> it's it the SFA component, then the permissions are
>> still spread around. All that has changed is instead of
>> having permission-modifying SECAs in components, you have
>> permission-modifying seed data in components. How was
>> anything "centralized?"
>>>
>>> I don't mean to pour cold water on your
>> enthusiasm, it's just that I don't see where
>> anything is being added or improved. It looks basically the
>> same, only slightly different.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Jacques Le Roux <ja...@les7arts.com>.
Big +1
But also I agree that Andrew made is best to communicate before commiting
For me 2 things were missing
1) A news on MLs, but it looks like Andrew sent one and it did not get through for a reason or another (things between head and
keyboard? ;o)
2) CTR mode : commit to fast before anybody had time to review anything
Jacques
From: "Adrian Crum" <ad...@yahoo.com>
>
> Don't get me wrong, I'm not resisting change. I commented on your design document that I'm in support of a security refactor. I'm
> sure others in the community would support that too.
>
> The problem is, this wasn't discussed with the community beforehand. No one was given an opportunity to provide input. It appears
> (and I know that this might not be true) that the design was created, some coding had been done, and THEN a document was drawn up
> and code committed shortly afterward.
>
> My recommendation would be to reboot this entire process to give the community a chance to be involved in the design.
>
> We should:
>
> 1. Send an email to the dev mailing list (and optionally the user list) asking for comments on the existing security framework and
> what they would like to see changed.
>
> 2. Compile the list into a set of design objectives.
>
> 3. Send the list to the dev mailing list and ask for suggestions for implementing the design objectives.
>
> 4. Compile a list of implementations and send it to the dev mailing list for a vote.
>
>>>From my perspective, that's how a developer community should work. Until those steps are followed, you're going to have a lot of
>>people asking the same questions I am - because they weren't involved and don't understand what you're doing.
>
> -Adrian
>
>
>
> --- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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 tried to cover everything in the document, but
>> that's impossible to do :)
>>
>> This is VERY similar to the existing security
>> implementation, and very similar to other security APIs out
>> there (JSecurity, Spring Security, etc). The slight
>> differences are:
>>
>> Easier to understand and follow. Reading the new permission
>> string format, you can see what is being checked. Nothing is
>> hidden. The logic used to determine granular access control
>> it defined on the permission itself. No more guessing where
>> permission logic is located.
>>
>> It is much easier to extend, create seed data which
>> overwrites the default permission logic references and use
>> your own custom logic to determine access. No need to
>> override service definitions or patch code (well once the
>> migration is complete) or comment out ECAs.
>>
>> So, now my questions for you are: What is missing? What
>> does this new API NOT do, which you are looking for?
>>
>>
>> Andrew
>>
>>
>> On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
>> >
>> > I read the Auto-Grant section. The question is, where
>> is the seed data shown in your code example located? If
>> it's it the SFA component, then the permissions are
>> still spread around. All that has changed is instead of
>> having permission-modifying SECAs in components, you have
>> permission-modifying seed data in components. How was
>> anything "centralized?"
>> >
>> > I don't mean to pour cold water on your
>> enthusiasm, it's just that I don't see where
>> anything is being added or improved. It looks basically the
>> same, only slightly different.
>> >
>> > -Adrian
>> >
>> >
>> >
>> >
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
Don't get me wrong, I'm not resisting change. I commented on your design document that I'm in support of a security refactor. I'm sure others in the community would support that too.
The problem is, this wasn't discussed with the community beforehand. No one was given an opportunity to provide input. It appears (and I know that this might not be true) that the design was created, some coding had been done, and THEN a document was drawn up and code committed shortly afterward.
My recommendation would be to reboot this entire process to give the community a chance to be involved in the design.
We should:
1. Send an email to the dev mailing list (and optionally the user list) asking for comments on the existing security framework and what they would like to see changed.
2. Compile the list into a set of design objectives.
3. Send the list to the dev mailing list and ask for suggestions for implementing the design objectives.
4. Compile a list of implementations and send it to the dev mailing list for a vote.
>From my perspective, that's how a developer community should work. Until those steps are followed, you're going to have a lot of people asking the same questions I am - because they weren't involved and don't understand what you're doing.
-Adrian
--- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> 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 tried to cover everything in the document, but
> that's impossible to do :)
>
> This is VERY similar to the existing security
> implementation, and very similar to other security APIs out
> there (JSecurity, Spring Security, etc). The slight
> differences are:
>
> Easier to understand and follow. Reading the new permission
> string format, you can see what is being checked. Nothing is
> hidden. The logic used to determine granular access control
> it defined on the permission itself. No more guessing where
> permission logic is located.
>
> It is much easier to extend, create seed data which
> overwrites the default permission logic references and use
> your own custom logic to determine access. No need to
> override service definitions or patch code (well once the
> migration is complete) or comment out ECAs.
>
> So, now my questions for you are: What is missing? What
> does this new API NOT do, which you are looking for?
>
>
> Andrew
>
>
> On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
> >
> > I read the Auto-Grant section. The question is, where
> is the seed data shown in your code example located? If
> it's it the SFA component, then the permissions are
> still spread around. All that has changed is instead of
> having permission-modifying SECAs in components, you have
> permission-modifying seed data in components. How was
> anything "centralized?"
> >
> > I don't mean to pour cold water on your
> enthusiasm, it's just that I don't see where
> anything is being added or improved. It looks basically the
> same, only slightly different.
> >
> > -Adrian
> >
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 security implementation, and very
similar to other security APIs out there (JSecurity, Spring Security,
etc). The slight differences are:
Easier to understand and follow. Reading the new permission string
format, you can see what is being checked. Nothing is hidden. The
logic used to determine granular access control it defined on the
permission itself. No more guessing where permission logic is located.
It is much easier to extend, create seed data which overwrites the
default permission logic references and use your own custom logic to
determine access. No need to override service definitions or patch
code (well once the migration is complete) or comment out ECAs.
So, now my questions for you are: What is missing? What does this new
API NOT do, which you are looking for?
Andrew
On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
>
> I read the Auto-Grant section. The question is, where is the seed
> data shown in your code example located? If it's it the SFA
> component, then the permissions are still spread around. All that
> has changed is instead of having permission-modifying SECAs in
> components, you have permission-modifying seed data in components.
> How was anything "centralized?"
>
> I don't mean to pour cold water on your enthusiasm, it's just that I
> don't see where anything is being added or improved. It looks
> basically the same, only slightly different.
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Andrew Zeneski <an...@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.
>
> While this is a really creative workaround for the
> limitations in the current security implementation, it is by
> no means an ideal solution. It is even more logic spread out
> in even more places making understanding and customizing
> authorization even more cumbersome.
>
> For these exact situations, the auto-grant functionality
> was implemented. So, instead of using ECAs to override
> permissions, you would define seed data (in the Asset Maint
> component, SFA, etc) which define which permissions are
> granted when a user is granted a specific application
> permission.
I read the Auto-Grant section. The question is, where is the seed data shown in your code example located? If it's it the SFA component, then the permissions are still spread around. All that has changed is instead of having permission-modifying SECAs in components, you have permission-modifying seed data in components. How was anything "centralized?"
I don't mean to pour cold water on your enthusiasm, it's just that I don't see where anything is being added or improved. It looks basically the same, only slightly different.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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
current security implementation, it is by no means an ideal solution.
It is even more logic spread out in even more places making
understanding and customizing authorization even more cumbersome.
For these exact situations, the auto-grant functionality was
implemented. So, instead of using ECAs to override permissions, you
would define seed data (in the Asset Maint component, SFA, etc) which
define which permissions are granted when a user is granted a specific
application permission.
There is a Use Case defined in the document (http://docs.ofbiz.org/x/-
B0) which explains how this would work for the SFA application.
Just for the record, nothing will break. The two frameworks can live
side by side during the migration process. It is my plan to knock this
out as quickly as possible, one application at a time. Also, I believe
HWM is going to help by providing some resources to assist in the
effort.
Andrew
On May 1, 2009, at 1:36 PM, Andrew Zeneski wrote:
> 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 functionality, or tied to services
> directly, the API should be the governor of all security. This means
> no more writing security logic in the functionality, and no more
> permission services attached directly to functionality (services or
> ecas). This is a bad design IMHO because it spreads the permission
> logic around in multiple places and makes it impossible to get the
> same results when checking permissions from different framework tools.
>
> -- We want to be consistent, and be able to obtain the same
> information from the UI or screen/form as we would get from a
> service call.
> -- Main point of contact is the Authorization interface.
>
> 2. Permission services become Dynamic Access (DA). Now instead of
> having permission services attached to services, we have Dynamic
> Access implementations which can be a compiled Java object, a Groovy
> script or a Service. My personal preference here is the Groovy
> script, but the API current supports all three. This DA logic is
> attached to a permission instead of a service.
>
> -- This allows for extending or changing the permission logic for a
> specific implementation/customization/application much easier. Since
> the DAs are all data driven, changing the seed data you can change
> the logic which is used. This means you no longer have to customize
> the services or logic in OFBiz to change the way authorization is
> handled for your company (or client); one less thing to worry about
> when merging customizations with the open source project.
>
> -- for groovy use "component://path/to/script.groovy" in the
> dynamicAccess field on SecurityPermission.
> -- for services use "service:serviceName" in the dynamicAccess field
> on SecurityPermission
> -- for objects use "org.ofbiz.path.to.Object (which implements
> DynamicAccess)" in the dynamicAccess field on SecurityPermission
>
> 3. Avoid having to check multiple permissions, for example
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission
> format which embeds all permissions which will be accepted:
>
> Example: update:party:contact:10000 - Update the contact information
> for party 10000
>
> This will allow anyone who has:
> "update" or "update:party" or "update:party:contact" or is granted
> record level access by the DA logic.
>
> 4. Define permission for users, not admins. Instead of looking for a
> static permission, set the permission to be checked at the most
> granular level. When doing so, admin users will always have
> permission and the API will handle user access using DA logic.
>
> -- see: http://docs.ofbiz.org/x/JR4
>
> That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a
> lot more details; interested parties are encouraged to read it
> through.
>
>
> Andrew
>
>
>
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Shi Yusen <sh...@langhua.cn>.
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 unit:opportunity
Regards,
Shi Yusen/Beijing Langhua Ltd.
在 2009-05-01五的 13:36 -0400，Andrew Zeneski写道：
> 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 functionality, or tied to services directly, the
> API should be the governor of all security. This means no more writing
> security logic in the functionality, and no more permission services
> attached directly to functionality (services or ecas). This is a bad
> design IMHO because it spreads the permission logic around in multiple
> places and makes it impossible to get the same results when checking
> permissions from different framework tools.
>
> -- We want to be consistent, and be able to obtain the same
> information from the UI or screen/form as we would get from a service
> call.
> -- Main point of contact is the Authorization interface.
>
> 2. Permission services become Dynamic Access (DA). Now instead of
> having permission services attached to services, we have Dynamic
> Access implementations which can be a compiled Java object, a Groovy
> script or a Service. My personal preference here is the Groovy script,
> but the API current supports all three. This DA logic is attached to a
> permission instead of a service.
>
> -- This allows for extending or changing the permission logic for a
> specific implementation/customization/application much easier. Since
> the DAs are all data driven, changing the seed data you can change the
> logic which is used. This means you no longer have to customize the
> services or logic in OFBiz to change the way authorization is handled
> for your company (or client); one less thing to worry about when
> merging customizations with the open source project.
>
> -- for groovy use "component://path/to/script.groovy" in the
> dynamicAccess field on SecurityPermission.
> -- for services use "service:serviceName" in the dynamicAccess field
> on SecurityPermission
> -- for objects use "org.ofbiz.path.to.Object (which implements
> DynamicAccess)" in the dynamicAccess field on SecurityPermission
>
> 3. Avoid having to check multiple permissions, for example
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission
> format which embeds all permissions which will be accepted:
>
> Example: update:party:contact:10000 - Update the contact information
> for party 10000
>
> This will allow anyone who has:
> "update" or "update:party" or "update:party:contact" or is granted
> record level access by the DA logic.
>
> 4. Define permission for users, not admins. Instead of looking for a
> static permission, set the permission to be checked at the most
> granular level. When doing so, admin users will always have permission
> and the API will handle user access using DA logic.
>
> -- see: http://docs.ofbiz.org/x/JR4
>
> That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a
> lot more details; interested parties are encouraged to read it through.
>
>
> Andrew
>
>
>
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Adrian,
>
> I must be missing something. Still using the Example component as an
> example: the service definition called a service permission, which
> called a script, which ultimately called Security.hasPermission.
> Your modification has the service definition use the <required-
> permissions> which ultimately calls authz.hasPermission(). So, both
> methods end up calling a single hasPermission() method. What changed?
>
> The only difference I see is that the permission string moved from a
> script to the service definition. Is that the desired benefit?
>
It is indeed the designed benefit. Previously, we had this:
1. A service with a permission service attached. The permission
service checked static permission, and possibly (not in the case of
the example component, but honestly this component doesn't utilize the
full potential of the new code) processed other logic which would
determine of the user had the ability to perform that function.
2. A screen definition which checked permissions, okay again the
example component doesn't utilize all the possibilities, but let's say
we wanted to add a delete button to the screen to delete the example.
Using the old method you would then call the has-permission screen
operator and check for a static permission probably something like
EXAMPLE_DELETE.
Now, let's say we want to allow anyone to create examples, only the
person who created the example and any admin can update or delete it.
Using what we had in the old model, the permission service logic would
need to be adjusted to grant permission to the owner of the example.
However, the screen operator will still only pickup the static
EXAMPLE_DELETE permission. We don't want to give everyone delete
access, we only want them to delete the examples they created. So,
only admins or users with EXAMPLE_DELETE would see the button.
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 will give all users access:example permission so they can access
the application, but only give admins the update and delete permissions.
Next we define the Dynamic Access logic. Very little code need, check
the example from the exampleId which is passed in the
permissionContext and part of the permission string (which we will
define in a moment) and if the owner is the userId return true,
otherwise return false. This can be groovy or a simple method if
desired. We then register this logic with the permissions in the seed
data file. The same logic can be attached to both update:example as
well as delete:example.
Now we will configure the services to include permissions. The
createExample will have no permission or set it to access:example to
make sure only users who can access the app can create (I have other
more complex ideas for this, but this is a simple example). The
updateExample service should be set with "update:example:${exampleId}"
as the permission, the deleteExample service set with "delete:example:$
{exampleId}" permission.
Finally, we configure the screen definition and add the delete button
(or update button whatever the case may be). But we do a permission
check here as well for "delete:example:${exampleId}" (note: exampleId
should be in the screen's context) to restrict the display of the
button.
Now, using the new API the button is displayed under two conditions:
1. the user is an admin and has delete:example permission
2. the user is the owner of the example
The exact same logic is used by the service engine when submitting the
request, so you can be sure that if the button was displayed then
permission will be granted when submitting the form.
Maybe later you want to change how this works. Maybe being the owner
is not enough, you must the be owner and have been active in the last
5 days. So, you simply edit the logic in the groovy (or simple method)
script and clear the cache. The new logic kicks in, effective in all
places which check that permission.
This is what I mean by 'centralized'. Instead of having security split
up between the Security API and the Service Engine Permission API,
everything is moved and centered around the permission.
Andrew
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
Where did that come from??!!
--- On Fri, 5/1/09, Adrian Crum <ad...@yahoo.com> wrote:
> From: Adrian Crum <ad...@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 <do...@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 who seem
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Adam Heath <do...@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 who seem
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Adam Heath <do...@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 what if it isn't perfect, we can always refactor it later" - as if we have all the time and resources in the world to do refactorings.
Btw, it's not a "fracas" - it's a gentlemanly disagreement. ;-)
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adam Heath <do...@brainfood.com>.
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 at all, the
> discussion is solely around whether or not code should have been
> implemented or not. Let's face it, these documents have been in front of
> you for over a week, and there was not a single objection or concern
> raised until today. I have only a limited amount of free time, and if I
> am going to following this effort through to the end, it needs to have a
> steady progression. So to be frank, get over it.
This can be summarized as release early, release often. If there are
problems with the actual implementation, then, by all means, give
details as to what you(not you Andrew, but whoever) take issue with.
But never put down someone who is *actually coding*, and, responding
to issues that are raised.
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?
ps: I've not actually read the document, nor actually looked at any of
this new code. I'm just commenting on the resulting fracas, if I can
use the term.
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.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 widgets which would automatically hide fields or make them
read only.
And what about defining permission requirements on request-maps in the
controller? They could automatically be applied at every stage of the
request, service calls, screen/form renders and delegator calls. Then
you could specify a required permission in once place only but if
needed also in various other places where you want to increase the
granularity.
Regards
Scott
On 3/05/2009, at 6:59 AM, Andrew Zeneski wrote:
> 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 scripts (or services) for
> permissions, but would be something along with it to make queries
> more secure. If we can come up with a generic way to implement this
> (or maybe only somewhat generic) I think it would be really useful.
>
> So far here are the list of other things which have been discussed
> and all work well with the current proposal:
>
> 1. SimpleRoleCheckDa - A simple role check dynamic access class.
> This would include some new tables to associate table name and role
> type IDs for simple role based checking. You would associate the
> table (i.e. ContentRole) with the permission as well as valid roles
> (ADMIN, OWNER, etc). The simple class can be attach to any
> permission which only requires very simple role based checks.
>
> 2. EntityUtil.filterByPermission() - A new method which (like
> filterByDate) takes a list of GenericValue objects and removes the
> ones which the user does not have permission to perform the
> operation on. The permission string would be passed and parsed using
> the value for the entity. Nice way to pull out data a user should
> not see, but limited as it will not work with the ELI.
>
> 3. Associate EntityCondition with permissions (correct me if I am
> wrong here) to have a unified way of limiting data in queries. If
> this is possible, the filterByPermission might not be necessary.
>
>
> Andrew
>
> On May 2, 2009, at 8:02 AM, Scott Gray wrote:
>
>> 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 the database independently
>> we provided some sort of security wrapped delegator to the
>> applications that intercepts database queries and automatically
>> appends the required entity expressions to the query.
>>
>> If it is a findOne/getRelatedOne query and no result is returned
>> then you throw some sort of authorization exception because
>> obviously the user didn't fit the criteria of someone able to view
>> the record. If it's a findList/getRelated then only the
>> permissible records would be returned.
>>
>> So instead of writing scripts for permissions we would write some
>> sort of entity expression. Just a thought.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:
>>
>>> 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 of migrating the applications, but
>>> that is going to change soon...
>>>
>>> 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 at all, the discussion is solely around whether or
>>> not code should have been implemented or not. Let's face it, these
>>> documents have been in front of you for over a week, and there was
>>> not a single objection or concern raised until today. I have only
>>> a limited amount of free time, and if I am going to following this
>>> effort through to the end, it needs to have a steady progression.
>>> So to be frank, get over it.
>>>
>>> Code is being worked on actively for this effort, and I am
>>> expecting more involvement as soon as the API is finalized. 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 in OFBiz.
>>>
>>> Andrew
>>>
>>>
>>>
>>> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>>>>> over time? of course it will but I think it's a much
>>>>> better base to work from.
>>>>
>>>> I don't know if you were around at the time, but I was. One of
>>>> the "weaknesses" Andrew is trying to fix with this latest effort
>>>> is the permissions services - another design he introduced a
>>>> couple years ago. Everyone went along with it and re-wrote code
>>>> to use service permissions. (I spent several weekends just
>>>> converting the accounting component over to the new security
>>>> implementation). Now we're being told "Oops, that design is
>>>> limited, let me try again."
>>>>
>>>> Why would anyone have any objection to opening this up to the
>>>> community before we start writing code? Maybe there are others
>>>> who see weaknesses in the new design. Give them a chance to offer
>>>> input.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 scripts (or services) for permissions,
but would be something along with it to make queries more secure. If
we can come up with a generic way to implement this (or maybe only
somewhat generic) I think it would be really useful.
So far here are the list of other things which have been discussed and
all work well with the current proposal:
1. SimpleRoleCheckDa - A simple role check dynamic access class. This
would include some new tables to associate table name and role type
IDs for simple role based checking. You would associate the table
(i.e. ContentRole) with the permission as well as valid roles (ADMIN,
OWNER, etc). The simple class can be attach to any permission which
only requires very simple role based checks.
2. EntityUtil.filterByPermission() - A new method which (like
filterByDate) takes a list of GenericValue objects and removes the
ones which the user does not have permission to perform the operation
on. The permission string would be passed and parsed using the value
for the entity. Nice way to pull out data a user should not see, but
limited as it will not work with the ELI.
3. Associate EntityCondition with permissions (correct me if I am
wrong here) to have a unified way of limiting data in queries. If this
is possible, the filterByPermission might not be necessary.
Andrew
On May 2, 2009, at 8:02 AM, Scott Gray wrote:
> 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 the database independently we
> provided some sort of security wrapped delegator to the applications
> that intercepts database queries and automatically appends the
> required entity expressions to the query.
>
> If it is a findOne/getRelatedOne query and no result is returned
> then you throw some sort of authorization exception because
> obviously the user didn't fit the criteria of someone able to view
> the record. If it's a findList/getRelated then only the permissible
> records would be returned.
>
> So instead of writing scripts for permissions we would write some
> sort of entity expression. Just a thought.
>
> Regards
> Scott
>
> On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:
>
>> 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 of migrating the applications, but that is
>> going to change soon...
>>
>> 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 at all, the discussion is solely around whether or not
>> code should have been implemented or not. Let's face it, these
>> documents have been in front of you for over a week, and there was
>> not a single objection or concern raised until today. I have only a
>> limited amount of free time, and if I am going to following this
>> effort through to the end, it needs to have a steady progression.
>> So to be frank, get over it.
>>
>> Code is being worked on actively for this effort, and I am
>> expecting more involvement as soon as the API is finalized. 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 in OFBiz.
>>
>> Andrew
>>
>>
>>
>> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>>
>>>
>>> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>>>> over time? of course it will but I think it's a much
>>>> better base to work from.
>>>
>>> I don't know if you were around at the time, but I was. One of the
>>> "weaknesses" Andrew is trying to fix with this latest effort is
>>> the permissions services - another design he introduced a couple
>>> years ago. Everyone went along with it and re-wrote code to use
>>> service permissions. (I spent several weekends just converting the
>>> accounting component over to the new security implementation). Now
>>> we're being told "Oops, that design is limited, let me try again."
>>>
>>> Why would anyone have any objection to opening this up to the
>>> community before we start writing code? Maybe there are others who
>>> see weaknesses in the new design. Give them a chance to offer input.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 5/2/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@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 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 the database
> independently we provided some sort of security wrapped
> delegator to the applications that intercepts database
> queries and automatically appends the required entity
> expressions to the query.
That's a great idea! My picture of an ideal security refactor is to make more of the framework "security-aware" - like your example here.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 the database independently we provided some
sort of security wrapped delegator to the applications that intercepts
database queries and automatically appends the required entity
expressions to the query.
If it is a findOne/getRelatedOne query and no result is returned then
you throw some sort of authorization exception because obviously the
user didn't fit the criteria of someone able to view the record. If
it's a findList/getRelated then only the permissible records would be
returned.
So instead of writing scripts for permissions we would write some sort
of entity expression. Just a thought.
Regards
Scott
On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:
> 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 of migrating the applications, but that is going
> to change soon...
>
> 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 at all, the discussion is solely around whether or not
> code should have been implemented or not. Let's face it, these
> documents have been in front of you for over a week, and there was
> not a single objection or concern raised until today. I have only a
> limited amount of free time, and if I am going to following this
> effort through to the end, it needs to have a steady progression. So
> to be frank, get over it.
>
> Code is being worked on actively for this effort, and I am expecting
> more involvement as soon as the API is finalized. 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 in OFBiz.
>
> Andrew
>
>
>
> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>
>>
>> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>>> over time? of course it will but I think it's a much
>>> better base to work from.
>>
>> I don't know if you were around at the time, but I was. One of the
>> "weaknesses" Andrew is trying to fix with this latest effort is the
>> permissions services - another design he introduced a couple years
>> ago. Everyone went along with it and re-wrote code to use service
>> permissions. (I spent several weekends just converting the
>> accounting component over to the new security implementation). Now
>> we're being told "Oops, that design is limited, let me try again."
>>
>> Why would anyone have any objection to opening this up to the
>> community before we start writing code? Maybe there are others who
>> see weaknesses in the new design. Give them a chance to offer input.
>>
>> -Adrian
>>
>>
>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Anil Patel <an...@hotwaxmedia.com>.
On May 1, 2009, at 10:19 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Anil Patel <an...@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 only started after Adrian and Jacques showed
>> interest by commenting on the page.
>
> The only interest I showed was that I agreed that OFBiz security
> could use improvement, and I suggested he use a third party library.
> I did not endorse or approve of his design.
>
Since then more energy has been spend in trying to get answer for "Why
you did not ask us first" then really understand the proposal and do
constructive feedback.
>> Andrew has been actively explaining his idea all this time.
>
> As I demonstrated in another reply, no he did not. Only a few days
> went by between introducing the idea and committing code.
>
What's wrong with that, as long as he did not disappear after
committing the code.
>> The work done till date is not blocking anybody, old
>> security system is still in place. New system is implemented
>> in example component so its lot easy for him to explain and
>> people to understand.
>
> What if the new work is a bad design? How will we know that until
> everyone has had time to evaluate it?
Implementation in example component demonstrates that he is prepared
to demonstrate new system and let people test and ask questions. If
few things are not implemented yet then either help with them or just
ask. Instead of asking to restart, its better if you ask for more
complex examples that prove abilities of new system. Help evaluate
instead of resisting.
>
>
>> People have different ways of working in community, Joe is
>> committer still all the time he creates Jira issue and
>> uploads his patch and most of time its somebody else who
>> does commits, but that's his way of working. If we
>> don't do what Joe does then why should Andrew do what
>> Adrian does.
>
> As far as I know, Joe submits patches for things he doesn't have
> commit rights to.
Not always that case.
>
>
>> I don't see any reason why we should start over.
>
> Do you see a reason why we shouldn't? Will the project suffer
> immensely if we pause and wait for others to comment? Is there some
> catastrophe looming that requires us to rush this through?
Project will not suffer immensely, at the same time its not suffering
because code is committed to trunk. I can ask same thing to others,
new system is not hurting anybody, we can still use old system.
>
>
>> All
>> the time we talk about making things easy so people will
>> contribute, Why do you want to resist a seasoned contributer
>> for working. I'll rather have expect community will
>> support. All the time he has been asking people to tell him
>> suggestions, wish list etc. Why not support him and get more
>> out of him instead.
>
> If we can't invite the community to participate - as I suggested -
> then that only proves what I suspect - that this is a design that is
> being foisted on the community.
>
There is no motivation for Andrew to do any such thing. Its always our
policy to contribute maximum possible (unless clients have objections)
to the community. I am really surprised and its really unfortunate
that you think like this.
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adam Heath <do...@brainfood.com>.
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 all the subversion branches too. You just can't push back to it.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adam Heath <do...@brainfood.com>.
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
> this being a great improvement is you and then once you spoke up Adrian
> followed.
A community has guidelines and procedures to follow. A *worldwide*
community has even more. There are long timelines that need to be
followed, before large-scale things can be done. A week of time is
*not* long enough. People need to have time to read and comprehend.
Quite often, you'll get a bunch of people immediately reading some new
proposed plan, in the first few days. But then it'll take a week or
two before they really start to understand what it is all about.
Consider how long you thought about this. I'm not talking about when
you actually sat down, and said, well, today is the day I'm really
going to do this. I'm talking about all the years you've had some
sort of thought in the back of your head about what you want to do.
> 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>.
>
> Let's look at the current tally:
>
> Anil, Scott and I have voiced approval for this proposal.
> You and Adrian have voiced disapproval.
>
> How does 3:2 justify a automatic revert? I think what you have done
> right here was very anti-community and EXTREMELY disrespectful to the
> one person who has been working with you 8 years to bring this project
> to where it is today. So, if your goal in reverting this was to piss me
> off and ruin what little respect I have left for you, it worked.
I haven't actually looked at the new security stuff, nor at the stuff
done to example. If the stuff you have done does *not* modify any
existing code(both security support classes, or examples, but you can
add extra helper methods), then I see no reason to do a revert. I
don't know if that's the case here.
However, I do think that David reverted a bit too early. He did *not*
give any warning, and just did it, and yes, that is a bit tyrannical.
If this really is a community, then it needs to be community *all the
time*.
Have you considered doing a git or mercurial branch of all these changes?
> I will personally revert the rest of the code over the next week.
Please don't go that far.
For instance, here's one thing that you and I have already discussed.
You added an AbstractResolver class, which scanned the classpath, and
loaded *every single org.ofbiz class*, just so you could find any
class that happened to implement an interface or extend a base class.
I then changed that code without telling you, to use the more
efficient javax.imageio.spi.ServiceRegistry(java 1.5, in java 1.6
there is java.util.ServiceLoader). So, here are the issues with this
particular exchange.
One, the code you wrote was not available for public discussion
*ahead* of time. If so, I would have commented about it(given some
time, more than what was allowed), and the revision history may have
been cleaner, by not having this class.
Two, I should have asked/told you about it before doing it. However,
I didn't know that there was some bold plan with this particular
class, and just thought it was something that had already existing in
ofbiz for a few weeks. I wasn't aware that this was part of some new,
long-term change. Maybe that was because I didn't see any singleton
message about it, nor any large thread about it, *before* I changed
anything.
The main reason I got back involved with OfBiz this time around was to
start upgrading the ofbiz code base to java 1.5 features, namely
generics, for-loops, auto-boxing, and other api usage; while doing so,
I've also done code walk-throughs, to find other various anti-patterns
or code duplication. I considered this particular change just another
one of those.
Re: Apology to David (was re: Authz API Discussion)
Posted by David E Jones <da...@hotwaxmedia.com>.
Thank you Andrew. I appreciate this. It helps smooth things out, but
don't feel like you have to apologize for my sake. This sort of
interaction (both from me to you and back) seems to be a common thing
in these discussions. We all care about the things we work on
including specific things we design or create and things we use on a
regular basis, so it seems like over the years these things happen a
lot. The conversation carries on regardless and eventually we all
settle down and discuss things at least somewhat rationally... it's
just a matter of not giving up and I really appreciate that you have
not given up on this security topic.
It's wonderful that OFBiz is so big these days and has so many people
actively involved. It is a log different from the early days when
writing and committing stuff was exactly what was done... usually
because nothing existed before or no one else was working on or
interested in working on a specific area. Also, if we changed
something that required a migration it didn't cause too much pain
because there weren't too many people using the stuff (and there
weren't many other users trying to keep up with the project, now there
are a lot).
Unfortunately this means that changes are much more carefully
monitored and have a much bigger impact so a lot more discussion is
required and things are a LOT more complicated. Personally I've given
up on the idea that I am even capable of designing and implementing
major changes by myself. I know that a certain level of research and
planning is necessary to be able to even present ideas, and
fortunately often other people do that too, and after I get involved
in those things I've been impressed by how much the collaboration
helps result in a cleaner and more effective solution. The security
stuff I did earlier this year was a great example, and that was all
started by someone (Michele) who had much more experience than me, and
then after researching and presenting possible solutions for OFBiz I
also got good feedback and was able to implement better things. I've
also been VERY fortunate in having other people participate in
implementation based on these efforts, which has seen the efforts
through with a LOT less of my own time required.
I guess in other words, overall I like it and it's great to have so
many good people involved. On that note, it's great that you're
getting much more involved again and that you're pushing all of us to
improve this messy part of OFBiz, ie the access control aspect of
security.
-David
On May 5, 2009, at 5:24 PM, Andrew Zeneski wrote:
> David,
>
> I would like to publicly apologize for my behavior this past
> weekend. While I do not believe you (or anyone else) has the right
> to revert any commit which does not directly effect the build or
> ability to run the trunk without first discussing with the author
> and giving them a chance to correct/revert the changes themselves; I
> also do not believe I should have responded to you the way I did.
> For that I wish to offer you my sincerest apology.
>
> I do not believe your actions were a direct attack on me personally,
> I responded abruptly in the heat of the moment. Having worked
> together on OFBiz for the last 8 years we both should have been able
> to rectify any differences without offending one another. Again, I
> apologize or not acting appropriately.
>
>
> Andrew
>
> On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote:
>
>> 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. Just because
>>> there are comments and feedback doesn't mean something has no
>>> merit, it just means that some adjustments to it might be able to
>>> improve it. That's what collaboration is all about, and I guess if
>>> you'd rather not do it than have other people comments on it and
>>> make changes to it then collaboration will be difficult.
>>
>> I am not offended by any comments or feedback, I was only offended
>> by your actions. Reverting the example was nothing more than a
>> power move by you. You can argue this if you wish, but the fact is
>> nothing else except for an example was effected, and there has been
>> no discussion by anyone to revert anything yet. If you did feel
>> that it was problematic, it should have been brought up if not to
>> the community then at least to me personally.
>>
>>>
>>> Just to clear that up... are you saying you would rather not do
>>> any of this than make some changes and refinements to it based on
>>> feedback? I hope that's not the case. My intent with this, as I
>>> explained in my email, is to make a compromise and allow
>>> development and improvement on this to continue without impact on
>>> other parts of the project until it is more ready for that.
>>
>> Your assumptions (as assumptions often are) completely wrong. Even
>> though say now you hope this isn't the case, you have publicly
>> accused me of this in your Notes On Security Changes document. What
>> have I been doing for the past week? It surely wasn't moving ahead
>> and checking in changes to all the applications to use a new
>> authorization pattern. What I have been doing is acquiring
>> additional needs/requirements comparing them to what I have planned
>> and trying to discuss with the community these changes. Refining
>> the API and including the requirements which I have gathered.
>>
>> You keep claiming that this new pattern is less flexible. While
>> that may (but I don't agree) be true to a certain extent, is it
>> also far MORE flexible when it comes to creating custom
>> implementations for vertical, custom or customized applications.
>>
>> Andrew
>>
>
Apology to David (was re: Authz API Discussion)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
David,
I would like to publicly apologize for my behavior this past weekend.
While I do not believe you (or anyone else) has the right to revert
any commit which does not directly effect the build or ability to run
the trunk without first discussing with the author and giving them a
chance to correct/revert the changes themselves; I also do not believe
I should have responded to you the way I did. For that I wish to offer
you my sincerest apology.
I do not believe your actions were a direct attack on me personally, I
responded abruptly in the heat of the moment. Having worked together
on OFBiz for the last 8 years we both should have been able to rectify
any differences without offending one another. Again, I apologize or
not acting appropriately.
Andrew
On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote:
> 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. Just because
>> there are comments and feedback doesn't mean something has no
>> merit, it just means that some adjustments to it might be able to
>> improve it. That's what collaboration is all about, and I guess if
>> you'd rather not do it than have other people comments on it and
>> make changes to it then collaboration will be difficult.
>
> I am not offended by any comments or feedback, I was only offended
> by your actions. Reverting the example was nothing more than a power
> move by you. You can argue this if you wish, but the fact is nothing
> else except for an example was effected, and there has been no
> discussion by anyone to revert anything yet. If you did feel that it
> was problematic, it should have been brought up if not to the
> community then at least to me personally.
>
>>
>> Just to clear that up... are you saying you would rather not do any
>> of this than make some changes and refinements to it based on
>> feedback? I hope that's not the case. My intent with this, as I
>> explained in my email, is to make a compromise and allow
>> development and improvement on this to continue without impact on
>> other parts of the project until it is more ready for that.
>
> Your assumptions (as assumptions often are) completely wrong. Even
> though say now you hope this isn't the case, you have publicly
> accused me of this in your Notes On Security Changes document. What
> have I been doing for the past week? It surely wasn't moving ahead
> and checking in changes to all the applications to use a new
> authorization pattern. What I have been doing is acquiring
> additional needs/requirements comparing them to what I have planned
> and trying to discuss with the community these changes. Refining the
> API and including the requirements which I have gathered.
>
> You keep claiming that this new pattern is less flexible. While that
> may (but I don't agree) be true to a certain extent, is it also far
> MORE flexible when it comes to creating custom implementations for
> vertical, custom or customized applications.
>
> Andrew
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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. Just because
> there are comments and feedback doesn't mean something has no merit,
> it just means that some adjustments to it might be able to improve
> it. That's what collaboration is all about, and I guess if you'd
> rather not do it than have other people comments on it and make
> changes to it then collaboration will be difficult.
I am not offended by any comments or feedback, I was only offended by
your actions. Reverting the example was nothing more than a power move
by you. You can argue this if you wish, but the fact is nothing else
except for an example was effected, and there has been no discussion
by anyone to revert anything yet. If you did feel that it was
problematic, it should have been brought up if not to the community
then at least to me personally.
>
> Just to clear that up... are you saying you would rather not do any
> of this than make some changes and refinements to it based on
> feedback? I hope that's not the case. My intent with this, as I
> explained in my email, is to make a compromise and allow development
> and improvement on this to continue without impact on other parts of
> the project until it is more ready for that.
Your assumptions (as assumptions often are) completely wrong. Even
though say now you hope this isn't the case, you have publicly accused
me of this in your Notes On Security Changes document. What have I
been doing for the past week? It surely wasn't moving ahead and
checking in changes to all the applications to use a new authorization
pattern. What I have been doing is acquiring additional needs/
requirements comparing them to what I have planned and trying to
discuss with the community these changes. Refining the API and
including the requirements which I have gathered.
You keep claiming that this new pattern is less flexible. While that
may (but I don't agree) be true to a certain extent, is it also far
MORE flexible when it comes to creating custom implementations for
vertical, custom or customized applications.
Andrew
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by David E Jones <da...@hotwaxmedia.com>.
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
> 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.
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Shi Yusen <sh...@langhua.cn>.
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.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by David E Jones <da...@hotwaxmedia.com>.
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.
Also, please don't be personally offended by this. Just because there
are comments and feedback doesn't mean something has no merit, it just
means that some adjustments to it might be able to improve it. That's
what collaboration is all about, and I guess if you'd rather not do it
than have other people comments on it and make changes to it then
collaboration will be difficult.
Just to clear that up... are you saying you would rather not do any of
this than make some changes and refinements to it based on feedback? I
hope that's not the case. My intent with this, as I explained in my
email, is to make a compromise and allow development and improvement
on this to continue without impact on other parts of the project until
it is more ready for that.
On a side note: I personally don't like the CTR way of doing things
and I like the pattern of discussion and covering any dissent before I
throw things in. However, in this case I did so because that seemed to
be the preferred working pattern and I'll admit it is a more efficient
way of doing things in some cases.
-David
On May 3, 2009, at 10:13 AM, 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 this being a great improvement is you and then once you
> spoke up Adrian followed.
>
> 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>.
>
> Let's look at the current tally:
>
> Anil, Scott and I have voiced approval for this proposal.
> You and Adrian have voiced disapproval.
>
> How does 3:2 justify a automatic revert? I think what you have done
> right here was very anti-community and EXTREMELY disrespectful to
> the one person who has been working with you 8 years to bring this
> project to where it is today. So, if your goal in reverting this was
> to piss me off and ruin what little respect I have left for you, it
> worked.
>
> I will personally revert the rest of the code over the next week.
>
>
> Andrew
>
>
>
> On May 3, 2009, at 2:12 AM, David E Jones wrote:
>
>>
>> This seemed like as good a message to respond to as any... nice
>> thread though!
>>
>> Since revisionist history seems popular in this thread here is my
>> own: One day I saw a Jira issue that pointed to some big documents
>> that were in someone's personal space on confluence, and pages I
>> had not seen referenced before. Unfortunately posting something to
>> confluence doesn't put it in front of very many eyes (ie only those
>> who watch the regular updates), more on that below. The next day I
>> saw some code going in, and then more and more. Being stuck
>> traveling at the time I didn't have time to review or comment, and
>> WHAM! there the code was and the ONLY to get any changes to it at
>> that point are to complain and fight like hell... being too tired
>> for that and too frustrated with that and various other things, I
>> just added my comments to a confluence page of my own, and this one
>> is in the open wiki and not in my personal space:
>>
>> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model
>>
>> How many people saw it? Well, no matter, if you are interested
>> please take a look now.
>>
>> 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 that flexibility was better than
>> ease in this case; and yes there is a creative way to invoke code
>> attached to permissions, but that is a bit inflexible IMO since
>> much permission logic involved multiple permissions... it's the
>> artifact we want the code attached to not the permission itself),
>> plus will cause migration pain for those updating. I'm not against
>> change and progress... unless it is change only for the sake of
>> change and founded on someone's subjective opinion of what is
>> better and easier.
>>
>> I see no side-by-side comparisons or concrete improvements or even
>> presentation of non-subjective issues to resolve (ie "this is
>> prettier, and easier", that's subjective), just a bunch of stuff in
>> the documents that is (in my subjective view) just a bunch of BS
>> that could have been generated by a "business software BS
>> generator". To find some great examples of those, search on google
>> for "bs generator", some fun results include:
>>
>> http://www.atrixnet.com/bs-generator.html
>> http://www.erikandanna.com/Humor/bullshit_generator.htm
>>
>> 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. If you think that's harsh then bash me like you've
>> bashed Adrian. Don't worry... go for it! I happen to have a button
>> with the letters "delete" on it, and I've been using it more and
>> more lately.
>>
>> As for how to move forward? How about we allow development to go on
>> as desired, and we'll discuss and modify best practices over time.
>> I will revert the changes to the example component (in the spirit
>> of Commit-Then-Review that some are so fond of... well there's my
>> review and a commit to boot!). BTW, thanks Andrew for isolating
>> those in a single commit. For examples going forward whle this is
>> still up in the air, examples of use new artifacts can be added (ie
>> new service, screen, etc), or a patch can be kept on a jira issue
>> for those who want to try it out. Once we have decided on best
>> practices moving forward, then we can change the example component.
>> Not sure how people want to move forward, but for now I have
>> attached the patch here (note that this can also be produced with a
>> "svn diff -r 770083:r770408 > AuthzExampleComponentSupport.patch"
>> from the ofbiz/framework/exmaple directory):
>>
>> https://issues.apache.org/jira/browse/OFBIZ-2383
>>
>> For other components let's not be too hasty. I won't get into a
>> commit war over the example component, but for the rest I'll gladly
>> do so since I think these changes have a negative ROI and this
>> whole thing has turned into a big old chest-thumping mess. That
>> being the case, sorry for joining in and thumping my own chest.
>>
>> Hopefully we can discuss some security objectives and common cases
>> we want to support, and then evaluate this new proposed approach
>> against them and/or establish a new approach based on this. There
>> definitely ARE areas where it is currently cumbersome to implement
>> specific security related requirements.
>>
>> -David
>>
>>
>> On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:
>>
>>> In the past, what 8 years that I have been working on OFBiz, not
>>> once have I had the masochistic urge to work on something which
>>> did not already have some sort of design. Never will you fine me
>>> wishing to refactor something without having the requirements
>>> already known. So, you will never find me coming to the table
>>> empty handed, and that is exactly what this sort of "request" is
>>> asking.
>>>
>>> Nor, do I want to review and discuss with someone an idea until
>>> they have their thoughts put together. So, what you can expect
>>> from me now, in the past and in the future is exactly your first
>>> statement. "Here is my design, what do you think..."
>>>
>>>
>>> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>>>
>>>>
>>>> It's not the same! There is a big difference between "Here's my
>>>> design, what do you think?" and "I'm interested in refactoring
>>>> the security framework. Could you help me with the design?"
>>>>
>>>> -Adrian
>>>>
>>>> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>>>>
>>>>> From: Scott Gray <sc...@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 at least we have a starting point.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>>>>
>>>>>>
>>>>>> How about we start over and collaborate on a design?
>>>>> Is that so much
>>>>>> different?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> --- On Fri, 5/1/09, Scott Gray
>>>>> <sc...@hotwaxmedia.com> wrote:
>>>>>>
>>>>>>> From: Scott Gray
>>>>> <sc...@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
>>>>>>> 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.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> --- On Fri, 5/1/09, Anil Patel
>>>>>>> <an...@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 only started after Adrian and
>>>>> Jacques
>>>>>>> showed
>>>>>>>>> interest by commenting on the page.
>>>>>>>>
>>>>>>>> The only interest I showed was that I agreed
>>>>> that
>>>>>>> OFBiz security could use improvement, and I
>>>>> suggested he use
>>>>>>> a third party library. I did not endorse or
>>>>> approve of his
>>>>>>> design.
>>>>>>>>
>>>>>>>>> Andrew has been actively explaining his
>>>>> idea all
>>>>>>> this time.
>>>>>>>>
>>>>>>>> As I demonstrated in another reply, no he did
>>>>> not.
>>>>>>> Only a few days went by between introducing the
>>>>> idea and
>>>>>>> committing code.
>>>>>>>>
>>>>>>>>> The work done till date is not blocking
>>>>> anybody,
>>>>>>> old
>>>>>>>>> security system is still in place. New
>>>>> system is
>>>>>>> implemented
>>>>>>>>> in example component so its lot easy for
>>>>> him to
>>>>>>> explain and
>>>>>>>>> people to understand.
>>>>>>>>
>>>>>>>> What if the new work is a bad design? How will
>>>>> we know
>>>>>>> that until everyone has had time to evaluate it?
>>>>>>>>
>>>>>>>>> People have different ways of working in
>>>>>>> community, Joe is
>>>>>>>>> committer still all the time he creates
>>>>> Jira issue
>>>>>>> and
>>>>>>>>> uploads his patch and most of time its
>>>>> somebody
>>>>>>> else who
>>>>>>>>> does commits, but that's his way of
>>>>> working.
>>>>>>> If we
>>>>>>>>> don't do what Joe does then why should
>>>>> Andrew
>>>>>>> do what
>>>>>>>>> Adrian does.
>>>>>>>>
>>>>>>>> As far as I know, Joe submits patches for
>>>>> things he
>>>>>>> doesn't have commit rights to.
>>>>>>>>
>>>>>>>>> I don't see any reason why we should
>>>>> start
>>>>>>> over.
>>>>>>>>
>>>>>>>> Do you see a reason why we shouldn't? Will
>>>>> the
>>>>>>> project suffer immensely if we pause and wait for
>>>>> others to
>>>>>>> comment? Is there some catastrophe looming that
>>>>> requires us
>>>>>>> to rush this through?
>>>>>>>>
>>>>>>>>> All
>>>>>>>>> the time we talk about making things easy
>>>>> so
>>>>>>> people will
>>>>>>>>> contribute, Why do you want to resist a
>>>>> seasoned
>>>>>>> contributer
>>>>>>>>> for working. I'll rather have expect
>>>>> community
>>>>>>> will
>>>>>>>>> support. All the time he has been asking
>>>>> people to
>>>>>>> tell him
>>>>>>>>> suggestions, wish list etc. Why not
>>>>> support him
>>>>>>> and get more
>>>>>>>>> out of him instead.
>>>>>>>>
>>>>>>>> If we can't invite the community to
>>>>> participate -
>>>>>>> as I suggested - then that only proves what I
>>>>> suspect - that
>>>>>>> this is a design that is being foisted on the
>>>>> community.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by David E Jones <da...@hotwaxmedia.com>.
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 have meant this sarcastically, but it's a really good point.
One of the things that is frustrating about a lot of stuff that
happens in OFBiz is that no one else does review it. I really
appreciate it when people are reviewing my code and "looking over my
shoulder" if you will, and a lot of stuff I've messed up has been
brought up that way (and sometimes people even hop in and fix it for
me! it's great!).
So yes, if I ever commit something you think causes more problems than
it solves, then by all means do revert it... and there is actually
precedence for this and people HAVE reverted stuff that I have
committed.
In short, yes please help out with the peer review that goes on here.
If more committers reviewed every commit with the intent of looking
for issues things would be a lot cleaner overall.
-David
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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
this being a great improvement is you and then once you spoke up
Adrian followed.
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>.
Let's look at the current tally:
Anil, Scott and I have voiced approval for this proposal.
You and Adrian have voiced disapproval.
How does 3:2 justify a automatic revert? I think what you have done
right here was very anti-community and EXTREMELY disrespectful to the
one person who has been working with you 8 years to bring this project
to where it is today. So, if your goal in reverting this was to piss
me off and ruin what little respect I have left for you, it worked.
I will personally revert the rest of the code over the next week.
Andrew
On May 3, 2009, at 2:12 AM, David E Jones wrote:
>
> This seemed like as good a message to respond to as any... nice
> thread though!
>
> Since revisionist history seems popular in this thread here is my
> own: One day I saw a Jira issue that pointed to some big documents
> that were in someone's personal space on confluence, and pages I had
> not seen referenced before. Unfortunately posting something to
> confluence doesn't put it in front of very many eyes (ie only those
> who watch the regular updates), more on that below. The next day I
> saw some code going in, and then more and more. Being stuck
> traveling at the time I didn't have time to review or comment, and
> WHAM! there the code was and the ONLY to get any changes to it at
> that point are to complain and fight like hell... being too tired
> for that and too frustrated with that and various other things, I
> just added my comments to a confluence page of my own, and this one
> is in the open wiki and not in my personal space:
>
> http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model
>
> How many people saw it? Well, no matter, if you are interested
> please take a look now.
>
> 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 that flexibility was better than ease in this
> case; and yes there is a creative way to invoke code attached to
> permissions, but that is a bit inflexible IMO since much permission
> logic involved multiple permissions... it's the artifact we want the
> code attached to not the permission itself), plus will cause
> migration pain for those updating. I'm not against change and
> progress... unless it is change only for the sake of change and
> founded on someone's subjective opinion of what is better and easier.
>
> I see no side-by-side comparisons or concrete improvements or even
> presentation of non-subjective issues to resolve (ie "this is
> prettier, and easier", that's subjective), just a bunch of stuff in
> the documents that is (in my subjective view) just a bunch of BS
> that could have been generated by a "business software BS
> generator". To find some great examples of those, search on google
> for "bs generator", some fun results include:
>
> http://www.atrixnet.com/bs-generator.html
> http://www.erikandanna.com/Humor/bullshit_generator.htm
>
> 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. If you think that's harsh then bash me like you've bashed
> Adrian. Don't worry... go for it! I happen to have a button with the
> letters "delete" on it, and I've been using it more and more lately.
>
> As for how to move forward? How about we allow development to go on
> as desired, and we'll discuss and modify best practices over time. I
> will revert the changes to the example component (in the spirit of
> Commit-Then-Review that some are so fond of... well there's my
> review and a commit to boot!). BTW, thanks Andrew for isolating
> those in a single commit. For examples going forward whle this is
> still up in the air, examples of use new artifacts can be added (ie
> new service, screen, etc), or a patch can be kept on a jira issue
> for those who want to try it out. Once we have decided on best
> practices moving forward, then we can change the example component.
> Not sure how people want to move forward, but for now I have
> attached the patch here (note that this can also be produced with a
> "svn diff -r 770083:r770408 > AuthzExampleComponentSupport.patch"
> from the ofbiz/framework/exmaple directory):
>
> https://issues.apache.org/jira/browse/OFBIZ-2383
>
> For other components let's not be too hasty. I won't get into a
> commit war over the example component, but for the rest I'll gladly
> do so since I think these changes have a negative ROI and this whole
> thing has turned into a big old chest-thumping mess. That being the
> case, sorry for joining in and thumping my own chest.
>
> Hopefully we can discuss some security objectives and common cases
> we want to support, and then evaluate this new proposed approach
> against them and/or establish a new approach based on this. There
> definitely ARE areas where it is currently cumbersome to implement
> specific security related requirements.
>
> -David
>
>
> On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:
>
>> In the past, what 8 years that I have been working on OFBiz, not
>> once have I had the masochistic urge to work on something which did
>> not already have some sort of design. Never will you fine me
>> wishing to refactor something without having the requirements
>> already known. So, you will never find me coming to the table empty
>> handed, and that is exactly what this sort of "request" is asking.
>>
>> Nor, do I want to review and discuss with someone an idea until
>> they have their thoughts put together. So, what you can expect from
>> me now, in the past and in the future is exactly your first
>> statement. "Here is my design, what do you think..."
>>
>>
>> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>>
>>>
>>> It's not the same! There is a big difference between "Here's my
>>> design, what do you think?" and "I'm interested in refactoring the
>>> security framework. Could you help me with the design?"
>>>
>>> -Adrian
>>>
>>> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>>>
>>>> From: Scott Gray <sc...@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 at least we have a starting point.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> How about we start over and collaborate on a design?
>>>> Is that so much
>>>>> different?
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> --- On Fri, 5/1/09, Scott Gray
>>>> <sc...@hotwaxmedia.com> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>> <sc...@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
>>>>>> 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.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>>>>>
>>>>>>>
>>>>>>> --- On Fri, 5/1/09, Anil Patel
>>>>>> <an...@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 only started after Adrian and
>>>> Jacques
>>>>>> showed
>>>>>>>> interest by commenting on the page.
>>>>>>>
>>>>>>> The only interest I showed was that I agreed
>>>> that
>>>>>> OFBiz security could use improvement, and I
>>>> suggested he use
>>>>>> a third party library. I did not endorse or
>>>> approve of his
>>>>>> design.
>>>>>>>
>>>>>>>> Andrew has been actively explaining his
>>>> idea all
>>>>>> this time.
>>>>>>>
>>>>>>> As I demonstrated in another reply, no he did
>>>> not.
>>>>>> Only a few days went by between introducing the
>>>> idea and
>>>>>> committing code.
>>>>>>>
>>>>>>>> The work done till date is not blocking
>>>> anybody,
>>>>>> old
>>>>>>>> security system is still in place. New
>>>> system is
>>>>>> implemented
>>>>>>>> in example component so its lot easy for
>>>> him to
>>>>>> explain and
>>>>>>>> people to understand.
>>>>>>>
>>>>>>> What if the new work is a bad design? How will
>>>> we know
>>>>>> that until everyone has had time to evaluate it?
>>>>>>>
>>>>>>>> People have different ways of working in
>>>>>> community, Joe is
>>>>>>>> committer still all the time he creates
>>>> Jira issue
>>>>>> and
>>>>>>>> uploads his patch and most of time its
>>>> somebody
>>>>>> else who
>>>>>>>> does commits, but that's his way of
>>>> working.
>>>>>> If we
>>>>>>>> don't do what Joe does then why should
>>>> Andrew
>>>>>> do what
>>>>>>>> Adrian does.
>>>>>>>
>>>>>>> As far as I know, Joe submits patches for
>>>> things he
>>>>>> doesn't have commit rights to.
>>>>>>>
>>>>>>>> I don't see any reason why we should
>>>> start
>>>>>> over.
>>>>>>>
>>>>>>> Do you see a reason why we shouldn't? Will
>>>> the
>>>>>> project suffer immensely if we pause and wait for
>>>> others to
>>>>>> comment? Is there some catastrophe looming that
>>>> requires us
>>>>>> to rush this through?
>>>>>>>
>>>>>>>> All
>>>>>>>> the time we talk about making things easy
>>>> so
>>>>>> people will
>>>>>>>> contribute, Why do you want to resist a
>>>> seasoned
>>>>>> contributer
>>>>>>>> for working. I'll rather have expect
>>>> community
>>>>>> will
>>>>>>>> support. All the time he has been asking
>>>> people to
>>>>>> tell him
>>>>>>>> suggestions, wish list etc. Why not
>>>> support him
>>>>>> and get more
>>>>>>>> out of him instead.
>>>>>>>
>>>>>>> If we can't invite the community to
>>>> participate -
>>>>>> as I suggested - then that only proves what I
>>>> suspect - that
>>>>>> this is a design that is being foisted on the
>>>> community.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
Mine has salsa splattered on it - I don't know what it says.
-Adrian
--- On Sun, 5/3/09, Jacques Le Roux <ja...@les7arts.com> wrote:
> From: Jacques Le Roux <ja...@les7arts.com>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: dev@ofbiz.apache.org
> Date: Sunday, May 3, 2009, 1:18 PM
> From: "Adam Heath" <do...@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 appreciating and using feedback
> naturally does. If you
> >> think that's harsh then bash me like
> you've bashed Adrian. Don't
> >> worry... go for it! I happen to have a button with
> the letters "delete"
> >> on it, and I've been using it more and more
> lately.
> >
> > (responding to just this paragraph, not that it really
> matters)
> >
> > Well, *I* have a key with *Delete* on it; does that
> make me more
> > important? Let's discuss the merits of
> "delete" versus "Delete", and
> > I'll commit 20 classes with 4200 lines in 3.7
> hours to change this on
> > everyone's keyboard.
>
> Mmm... mine is "Suppr" :D
>
> Jacques
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adam Heath" <do...@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 appreciating and using feedback naturally does. If you
>> think that's harsh then bash me like you've bashed Adrian. Don't
>> worry... go for it! I happen to have a button with the letters "delete"
>> on it, and I've been using it more and more lately.
>
> (responding to just this paragraph, not that it really matters)
>
> Well, *I* have a key with *Delete* on it; does that make me more
> important? Let's discuss the merits of "delete" versus "Delete", and
> I'll commit 20 classes with 4200 lines in 3.7 hours to change this on
> everyone's keyboard.
Mmm... mine is "Suppr" :D
Jacques
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adam Heath <do...@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 appreciating and using feedback naturally does. If you
> think that's harsh then bash me like you've bashed Adrian. Don't
> worry... go for it! I happen to have a button with the letters "delete"
> on it, and I've been using it more and more lately.
(responding to just this paragraph, not that it really matters)
Well, *I* have a key with *Delete* on it; does that make me more
important? Let's discuss the merits of "delete" versus "Delete", and
I'll commit 20 classes with 4200 lines in 3.7 hours to change this on
everyone's keyboard.
But, actually, yeah, for something as low-level critical as security,
anything less than a week of discussion is completely right out. If
it is going to affect *all* code *everywhere*, then you have to allow
for *everyone* to have time to comment on it. Not everyone is paid to
work directly on ofbiz; some do it in their spare time. This means at
least 2 weekends of waiting. Sometimes, even a month, so you can get
all the various eyes on it. This is something I learned in my long
association with Debian.
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
On May 3, 2009, at 2:43 PM, Anil Patel wrote:
> Inline.
>
> On May 3, 2009, at 1:36 PM, David E Jones wrote:
>
>>
>> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sat, 5/2/09, David E Jones <da...@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 that
>>>> flexibility was better than ease in this case; and yes there
>>>> is a creative way to invoke code attached to permissions,
>>>> but that is a bit inflexible IMO since much permission logic
>>>> involved multiple permissions... it's the artifact we
>>>> want the code attached to not the permission itself)
>>>
>>> I've been thinking about that aspect of it. If I understand
>>> correctly, here are two of the issues being addressed by the new
>>> security:
>>>
>>> 1. Permission checking is being done in scripts, so a programmer
>>> is required to change the permission checking logic. An ordinary
>>> systems administrator with no knowledge of mini-language would not
>>> be able to change how permissions are checked. The new permission
>>> string is supposed to make changes to permission checking easier
>>> for the non-programmer administrators.
> I see potential in proposed system. Now we have a logical string
> that defines permission requirements. If the string points to entity
> then check permission service will do the job. In case string points
> to logical entity in system like "sfa:contact" then permission check
> service can look in auto-grant data to find dependency.
> We can build tools for Administrator to add entity level permission,
> e.g "sfa:contact" will have partymgr:party as auto-grant.
>
>>>
>>>
>>> 2. Permission checking isn't consistent. Two similar branches of
>>> logic will check permissions in two different ways: one will check
>>> a permission string, and another will run a script. This is common
>>> in the UI versus the services called by the UI. A simple "has
>>> permission" check is done in the UI, and then the service invoked
>>> runs a script to check permissions.
>>>
>>> I agree with you that substituting the permission service with a
>>> permission string is too inflexible.
> I don't agree with inflexible part. Instead existing way of
> embedding permission rules in services are too rigid/static. I
> cannot query permission check service to find out what kind of
> permission is required. The new permission string thing lets me do
> that. I can query service model to get information on what kind of
> permissions are required to run that service. This allows me to
> build tools that makes administrator life lot easy.
> The auto-grant extension make it so much flexible because its data
> driven.
>
>>>
>>>
>>> One of the ideas I've been toying with is the idea of a permission
>>> expression. I started writing some code for that and was going to
>>> put it in Jira, but I decided to put it on the shelf until the
>>> dust settles from this thread.
>>>
>>> Let's say we took Andrew's new permission string and gave it more
>>> oomph - where it could contain functions and such. (The expression
>>> language would be simple enough for common administrators to
>>> understand.) That could eliminate many of the permission checking
>>> scripts. In effect, the permission string becomes a mini-script.
>>> This mini-script could be used anywhere a permission string is
>>> being used now.
>>>
> Do you mean Administrator will exit servicedef file? I think its too
> much to expect from them. Also it will require redeployment.
I mean edit.
>
>
>>> One of the problems I have with what has been proposed so far is
>>> that the permission string can be ambiguous when it comes to
>>> inserting parameters. For example, "update:example:${exampleId}" -
>>> what does that mean? There's no way to tell by looking at it. It
>>> would be preferable to have something like "update:example +
>>> relatedTo(exampleId)". That permission tells me something - it
>>> requires update:example permission and the user must be related to
>>> exampleId in some way.
>>>
> I don't see how adding relatedTo adds meaning. Dynamic access thing
> comes into play only if we are going to check if user is related to
> a particular data.
>
>>> I think permission expressions would solve both of the issues above.
>>
>> Part of the point (if I remember right) of putting permission logic
>> into little services was to help keep it consistent when that
>> service is called in multiple places, especially in the input
>> processing service and the output generating screen.
>>
>> If we have cases where a direct permission check is done on the
>> screen and a permission service is used for the input processing
>> service, then we should really change the screen to also call that
>> same service.
>>
>> I guess the real trick with all of this is to make any easy way to
>> do dynamic permissions. So far we have these approaches on the
>> table (sorry if I missed any others...):
>>
>> 1. the current recommended practice of writing a service to perform
>> permission logic (service can be implemented in simple-method,
>> java, groovy, etc; normally the easiest way to write and maintain
>> (and in the future to create tools to help write and maintain) is a
>> simple-method XML snippet)
>>
>> 2. Andrew's new pattern of attaching a groovy script to certain
>> permission strings to override the normal behavior of that string
>>
>> 3. Adrian's idea to create some new expression (possibly extend
>> what Andrew has done) and add functions to the permission string
>> itself (which might eventually have boolean logic and other things,
>> and be a little expression language of its own)
>>
>> Does that sound about right?
>>
>> When comparing these the big question for me is what will be
>> easiest for users to maintain, especially less technical users (ie
>> non-programmers, or I guess also programmers with little time and
>> patience)?
>>
>> In general I don't know if we'll EVER be able to come up with
>> something that allows non-technical users to easily configure
>> dynamic permissions to handle any possible situation. On the other
>> hand, maybe we can create something that handles most common cases
>> (including both functionality level and simple record level cases)
>> and leave in extension points so that it is possible to create more
>> complicated permission logic when needed.
>>
>> In other words, however we do this we probably want some
>> configurable permissions that cover most stuff, and then extension
>> mechanisms to drop-down to lower level tools. That is the pattern
>> used in pretty much all of the OFBiz framework tools, and it would
>> be good to apply it here too.
>>
>> A quick note on the extension mechanism: another pattern that has
>> emerged over time is to allow programmers to create custom logic
>> and put it somewhere that less-technical users can refer to. The
>> reason for this is that the custom stuff becomes a sort of tool
>> that can be documented and then used (but not manipulated) by less
>> technical users as part of their configuration. In other words the
>> pattern would look like the configuration part of things having the
>> ability to reference the custom logic part of things, and not the
>> other way around (to make it clear, that's a big distinction
>> between #1 and #2 above, and I'm not sure about #3 since it seems
>> to mostly be meant to internalize things in the permission string/
>> expression instead of referring to external stuff, but could
>> certainly easily point explicitly to external stuff).
>>
>> Anyway, THANK YOU Adrian, this message is a breath of fresh air
>> (part of why I changed the subject line :) ) and it's great to
>> discuss actual issues and patterns and possible solutions.
>>
>> -David
>>
>
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
Inline.
On May 3, 2009, at 1:36 PM, David E Jones wrote:
>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <da...@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 that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand
>> correctly, here are two of the issues being addressed by the new
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is
>> required to change the permission checking logic. An ordinary
>> systems administrator with no knowledge of mini-language would not
>> be able to change how permissions are checked. The new permission
>> string is supposed to make changes to permission checking easier
>> for the non-programmer administrators.
I see potential in proposed system. Now we have a logical string that
defines permission requirements. If the string points to entity then
check permission service will do the job. In case string points to
logical entity in system like "sfa:contact" then permission check
service can look in auto-grant data to find dependency.
We can build tools for Administrator to add entity level permission,
e.g "sfa:contact" will have partymgr:party as auto-grant.
>>
>>
>> 2. Permission checking isn't consistent. Two similar branches of
>> logic will check permissions in two different ways: one will check
>> a permission string, and another will run a script. This is common
>> in the UI versus the services called by the UI. A simple "has
>> permission" check is done in the UI, and then the service invoked
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a
>> permission string is too inflexible.
I don't agree with inflexible part. Instead existing way of embedding
permission rules in services are too rigid/static. I cannot query
permission check service to find out what kind of permission is
required. The new permission string thing lets me do that. I can query
service model to get information on what kind of permissions are
required to run that service. This allows me to build tools that makes
administrator life lot easy.
The auto-grant extension make it so much flexible because its data
driven.
>>
>>
>> One of the ideas I've been toying with is the idea of a permission
>> expression. I started writing some code for that and was going to
>> put it in Jira, but I decided to put it on the shelf until the dust
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more
>> oomph - where it could contain functions and such. (The expression
>> language would be simple enough for common administrators to
>> understand.) That could eliminate many of the permission checking
>> scripts. In effect, the permission string becomes a mini-script.
>> This mini-script could be used anywhere a permission string is
>> being used now.
>>
Do you mean Administrator will exit servicedef file? I think its too
much to expect from them. Also it will require redeployment.
>> One of the problems I have with what has been proposed so far is
>> that the permission string can be ambiguous when it comes to
>> inserting parameters. For example, "update:example:${exampleId}" -
>> what does that mean? There's no way to tell by looking at it. It
>> would be preferable to have something like "update:example +
>> relatedTo(exampleId)". That permission tells me something - it
>> requires update:example permission and the user must be related to
>> exampleId in some way.
>>
I don't see how adding relatedTo adds meaning. Dynamic access thing
comes into play only if we are going to check if user is related to a
particular data.
>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic
> into little services was to help keep it consistent when that
> service is called in multiple places, especially in the input
> processing service and the output generating screen.
>
> If we have cases where a direct permission check is done on the
> screen and a permission service is used for the input processing
> service, then we should really change the screen to also call that
> same service.
>
> I guess the real trick with all of this is to make any easy way to
> do dynamic permissions. So far we have these approaches on the table
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform
> permission logic (service can be implemented in simple-method, java,
> groovy, etc; normally the easiest way to write and maintain (and in
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>
> 2. Andrew's new pattern of attaching a groovy script to certain
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what
> Andrew has done) and add functions to the permission string itself
> (which might eventually have boolean logic and other things, and be
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and
> patience)?
>
> In general I don't know if we'll EVER be able to come up with
> something that allows non-technical users to easily configure
> dynamic permissions to handle any possible situation. On the other
> hand, maybe we can create something that handles most common cases
> (including both functionality level and simple record level cases)
> and leave in extension points so that it is possible to create more
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some
> configurable permissions that cover most stuff, and then extension
> mechanisms to drop-down to lower level tools. That is the pattern
> used in pretty much all of the OFBiz framework tools, and it would
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has
> emerged over time is to allow programmers to create custom logic and
> put it somewhere that less-technical users can refer to. The reason
> for this is that the custom stuff becomes a sort of tool that can be
> documented and then used (but not manipulated) by less technical
> users as part of their configuration. In other words the pattern
> would look like the configuration part of things having the ability
> to reference the custom logic part of things, and not the other way
> around (to make it clear, that's a big distinction between #1 and #2
> above, and I'm not sure about #3 since it seems to mostly be meant
> to internalize things in the permission string/expression instead of
> referring to external stuff, but could certainly easily point
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air
> (part of why I changed the subject line :) ) and it's great to
> discuss actual issues and patterns and possible solutions.
>
> -David
>
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by an...@hotwaxmedia.com.
Just for clarification, my proposal did include a new way to write
permissions using groovy, but it also supports permissions as services
ad well as a new interface to implement very common permission
checking routines for re-usability.
This was only one part of the proposal, the main focus is on not
attaching the logic directly to the service instead it is attached to
a verbose permission. The reason for this is to make customization of
the permission logic easy to maintain, and not require modifying the
actual application.
The point is, the groovy part you keep referring to is just a minor
extra and not the focus of the framework.
Andrew
On May 3, 2009, at 1:38 PM, David E Jones
<da...@hotwaxmedia.com> wrote:
>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <da...@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 that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand
>> correctly, here are two of the issues being addressed by the new
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is
>> required to change the permission checking logic. An ordinary
>> systems administrator with no knowledge of mini-language would not
>> be able to change how permissions are checked. The new permission
>> string is supposed to make changes to permission checking easier
>> for the non-programmer administrators.
>>
>> 2. Permission checking isn't consistent. Two similar branches of
>> logic will check permissions in two different ways: one will check
>> a permission string, and another will run a script. This is common
>> in the UI versus the services called by the UI. A simple "has
>> permission" check is done in the UI, and then the service invoked
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a
>> permission string is too inflexible.
>>
>> One of the ideas I've been toying with is the idea of a permission
>> expression. I started writing some code for that and was going to
>> put it in Jira, but I decided to put it on the shelf until the dust
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more
>> oomph - where it could contain functions and such. (The expression
>> language would be simple enough for common administrators to
>> understand.) That could eliminate many of the permission checking
>> scripts. In effect, the permission string becomes a mini-script.
>> This mini-script could be used anywhere a permission string is
>> being used now.
>>
>> One of the problems I have with what has been proposed so far is
>> that the permission string can be ambiguous when it comes to
>> inserting parameters. For example, "update:example:${exampleId}" -
>> what does that mean? There's no way to tell by looking at it. It
>> would be preferable to have something like "update:example +
>> relatedTo(exampleId)". That permission tells me something - it
>> requires update:example permission and the user must be related to
>> exampleId in some way.
>>
>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic
> into little services was to help keep it consistent when that
> service is called in multiple places, especially in the input
> processing service and the output generating screen.
>
> If we have cases where a direct permission check is done on the
> screen and a permission service is used for the input processing
> service, then we should really change the screen to also call that
> same service.
>
> I guess the real trick with all of this is to make any easy way to
> do dynamic permissions. So far we have these approaches on the table
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform
> permission logic (service can be implemented in simple-method, java,
> groovy, etc; normally the easiest way to write and maintain (and in
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>
> 2. Andrew's new pattern of attaching a groovy script to certain
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what
> Andrew has done) and add functions to the permission string itself
> (which might eventually have boolean logic and other things, and be
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and
> patience)?
>
> In general I don't know if we'll EVER be able to come up with
> something that allows non-technical users to easily configure
> dynamic permissions to handle any possible situation. On the other
> hand, maybe we can create something that handles most common cases
> (including both functionality level and simple record level cases)
> and leave in extension points so that it is possible to create more
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some
> configurable permissions that cover most stuff, and then extension
> mechanisms to drop-down to lower level tools. That is the pattern
> used in pretty much all of the OFBiz framework tools, and it would
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has
> emerged over time is to allow programmers to create custom logic and
> put it somewhere that less-technical users can refer to. The reason
> for this is that the custom stuff becomes a sort of tool that can be
> documented and then used (but not manipulated) by less technical
> users as part of their configuration. In other words the pattern
> would look like the configuration part of things having the ability
> to reference the custom logic part of things, and not the other way
> around (to make it clear, that's a big distinction between #1 and #2
> above, and I'm not sure about #3 since it seems to mostly be meant
> to internalize things in the permission string/expression instead of
> referring to external stuff, but could certainly easily point
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air
> (part of why I changed the subject line :) ) and it's great to
> discuss actual issues and patterns and possible solutions.
>
> -David
>
Re: Easier Dynamic Permissions
Posted by Adam Heath <do...@brainfood.com>.
Don't need to actually respond to any particular thing David said,
just reusing his change of subject for my email.
==
PermissionNameOrPattern Command Action Roles
----------------------- ------- ------ -----
/Path/To/Resource UPDATE ALLOW \
(FOO_ADMIN|FOO_UPDATE)&FOO_TRAINED
/Path/Pattern.* CREATE ALLOW \
(FOO_ADMIN|FOO_CREATE)&FOO_TRAINED
PARTY_MGR READ ALLOW \
PARTY_ADMIN&PARTY_TRAINED
==
We have something similiar to this in our client apps. It hasn't yet
made it to the base webslinger code. It's not any kind of fancy
parser. Just tab separated(for now, that would have to change if the
Name allowed spaces).
The 'framework' is the parser, and the api that can be called by
code($resource.userAllowed($user, $command)). The
Command/Action/Roles are not hard-coded.
Again, I haven't actually read the proposal. The above makes the
application code easy to understand. It's not polluted with
boiler-plate security code; instead, it has a simple string that can
be descriptive of what it is checking. It allows clients to change
the security(based on whatever policy they have), without having to
understand any kind of programming logic.
I'm fairly good with javacc. The above would be *simple* to write a
javacc parser for. I've got a SQL parser sitting in the wings, as is
what I was actually working on this weekend, trying to add it to ofbiz.
Re: Easier Dynamic Permissions
Posted by Adam Heath <do...@brainfood.com>.
Anil Patel wrote:
>> Part of the point (if I remember right) of putting permission logic
>> into little services was to help keep it consistent when that service
>> is called in multiple places, especially in the input processing
>> service and the output generating screen.
> How is writing "acctgInvoicePermissionCheck" different from
> "update:acctmgr:invoice". I cannot interpret anything out of
> acctgInvoicePermissionCheck but string does tell me something which goes
> in line with convention over configurations practice.
acctmgr:invoice:update would be better, imho. But I can see it argued
both ways.
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
On May 3, 2009, at 1:36 PM, David E Jones wrote:
>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <da...@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 that
>>> flexibility was better than ease in this case; and yes there
>>> is a creative way to invoke code attached to permissions,
>>> but that is a bit inflexible IMO since much permission logic
>>> involved multiple permissions... it's the artifact we
>>> want the code attached to not the permission itself)
>>
>> I've been thinking about that aspect of it. If I understand
>> correctly, here are two of the issues being addressed by the new
>> security:
>>
>> 1. Permission checking is being done in scripts, so a programmer is
>> required to change the permission checking logic. An ordinary
>> systems administrator with no knowledge of mini-language would not
>> be able to change how permissions are checked. The new permission
>> string is supposed to make changes to permission checking easier
>> for the non-programmer administrators.
>>
>> 2. Permission checking isn't consistent. Two similar branches of
>> logic will check permissions in two different ways: one will check
>> a permission string, and another will run a script. This is common
>> in the UI versus the services called by the UI. A simple "has
>> permission" check is done in the UI, and then the service invoked
>> runs a script to check permissions.
>>
>> I agree with you that substituting the permission service with a
>> permission string is too inflexible.
>>
>> One of the ideas I've been toying with is the idea of a permission
>> expression. I started writing some code for that and was going to
>> put it in Jira, but I decided to put it on the shelf until the dust
>> settles from this thread.
>>
>> Let's say we took Andrew's new permission string and gave it more
>> oomph - where it could contain functions and such. (The expression
>> language would be simple enough for common administrators to
>> understand.) That could eliminate many of the permission checking
>> scripts. In effect, the permission string becomes a mini-script.
>> This mini-script could be used anywhere a permission string is
>> being used now.
>>
>> One of the problems I have with what has been proposed so far is
>> that the permission string can be ambiguous when it comes to
>> inserting parameters. For example, "update:example:${exampleId}" -
>> what does that mean? There's no way to tell by looking at it. It
>> would be preferable to have something like "update:example +
>> relatedTo(exampleId)". That permission tells me something - it
>> requires update:example permission and the user must be related to
>> exampleId in some way.
>>
>> I think permission expressions would solve both of the issues above.
>
> Part of the point (if I remember right) of putting permission logic
> into little services was to help keep it consistent when that
> service is called in multiple places, especially in the input
> processing service and the output generating screen.
How is writing "acctgInvoicePermissionCheck" different from
"update:acctmgr:invoice". I cannot interpret anything out of
acctgInvoicePermissionCheck but string does tell me something which
goes in line with convention over configurations practice.
>
>
> If we have cases where a direct permission check is done on the
> screen and a permission service is used for the input processing
> service, then we should really change the screen to also call that
> same service.
Forms and screens don't always work on data from one entity. I can use
string to check "update:ecommerce:billingAndShippingAddress" and use
auto-grant to power permission check service. If data for auto-grant
is set right we will not have to write any custom code to check
permission for most cases.
>
>
> I guess the real trick with all of this is to make any easy way to
> do dynamic permissions. So far we have these approaches on the table
> (sorry if I missed any others...):
>
> 1. the current recommended practice of writing a service to perform
> permission logic (service can be implemented in simple-method, java,
> groovy, etc; normally the easiest way to write and maintain (and in
> the future to create tools to help write and maintain) is a simple-
> method XML snippet)
>
Too many rules embedded in services is bad. They make administrators
life difficult. I have to find and read permission check service to
figure out what permissions should be given to user.
> 2. Andrew's new pattern of attaching a groovy script to certain
> permission strings to override the normal behavior of that string
>
> 3. Adrian's idea to create some new expression (possibly extend what
> Andrew has done) and add functions to the permission string itself
> (which might eventually have boolean logic and other things, and be
> a little expression language of its own)
>
> Does that sound about right?
>
> When comparing these the big question for me is what will be easiest
> for users to maintain, especially less technical users (ie non-
> programmers, or I guess also programmers with little time and
> patience)?
Something that does not require me to look at code and redeploy
application.
>
>
> In general I don't know if we'll EVER be able to come up with
> something that allows non-technical users to easily configure
> dynamic permissions to handle any possible situation. On the other
> hand, maybe we can create something that handles most common cases
> (including both functionality level and simple record level cases)
> and leave in extension points so that it is possible to create more
> complicated permission logic when needed.
>
> In other words, however we do this we probably want some
> configurable permissions that cover most stuff, and then extension
> mechanisms to drop-down to lower level tools. That is the pattern
> used in pretty much all of the OFBiz framework tools, and it would
> be good to apply it here too.
>
> A quick note on the extension mechanism: another pattern that has
> emerged over time is to allow programmers to create custom logic and
> put it somewhere that less-technical users can refer to. The reason
> for this is that the custom stuff becomes a sort of tool that can be
> documented and then used (but not manipulated) by less technical
> users as part of their configuration. In other words the pattern
> would look like the configuration part of things having the ability
> to reference the custom logic part of things, and not the other way
> around (to make it clear, that's a big distinction between #1 and #2
> above, and I'm not sure about #3 since it seems to mostly be meant
> to internalize things in the permission string/expression instead of
> referring to external stuff, but could certainly easily point
> explicitly to external stuff).
>
> Anyway, THANK YOU Adrian, this message is a breath of fresh air
> (part of why I changed the subject line :) ) and it's great to
> discuss actual issues and patterns and possible solutions.
>
> -David
>
Easier Dynamic Permissions (was: Authz API Discussion)
Posted by David E Jones <da...@hotwaxmedia.com>.
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
> --- On Sat, 5/2/09, David E Jones <da...@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 that
>> flexibility was better than ease in this case; and yes there
>> is a creative way to invoke code attached to permissions,
>> but that is a bit inflexible IMO since much permission logic
>> involved multiple permissions... it's the artifact we
>> want the code attached to not the permission itself)
>
> I've been thinking about that aspect of it. If I understand
> correctly, here are two of the issues being addressed by the new
> security:
>
> 1. Permission checking is being done in scripts, so a programmer is
> required to change the permission checking logic. An ordinary
> systems administrator with no knowledge of mini-language would not
> be able to change how permissions are checked. The new permission
> string is supposed to make changes to permission checking easier for
> the non-programmer administrators.
>
> 2. Permission checking isn't consistent. Two similar branches of
> logic will check permissions in two different ways: one will check a
> permission string, and another will run a script. This is common in
> the UI versus the services called by the UI. A simple "has
> permission" check is done in the UI, and then the service invoked
> runs a script to check permissions.
>
> I agree with you that substituting the permission service with a
> permission string is too inflexible.
>
> One of the ideas I've been toying with is the idea of a permission
> expression. I started writing some code for that and was going to
> put it in Jira, but I decided to put it on the shelf until the dust
> settles from this thread.
>
> Let's say we took Andrew's new permission string and gave it more
> oomph - where it could contain functions and such. (The expression
> language would be simple enough for common administrators to
> understand.) That could eliminate many of the permission checking
> scripts. In effect, the permission string becomes a mini-script.
> This mini-script could be used anywhere a permission string is being
> used now.
>
> One of the problems I have with what has been proposed so far is
> that the permission string can be ambiguous when it comes to
> inserting parameters. For example, "update:example:${exampleId}" -
> what does that mean? There's no way to tell by looking at it. It
> would be preferable to have something like "update:example +
> relatedTo(exampleId)". That permission tells me something - it
> requires update:example permission and the user must be related to
> exampleId in some way.
>
> I think permission expressions would solve both of the issues above.
Part of the point (if I remember right) of putting permission logic
into little services was to help keep it consistent when that service
is called in multiple places, especially in the input processing
service and the output generating screen.
If we have cases where a direct permission check is done on the screen
and a permission service is used for the input processing service,
then we should really change the screen to also call that same service.
I guess the real trick with all of this is to make any easy way to do
dynamic permissions. So far we have these approaches on the table
(sorry if I missed any others...):
1. the current recommended practice of writing a service to perform
permission logic (service can be implemented in simple-method, java,
groovy, etc; normally the easiest way to write and maintain (and in
the future to create tools to help write and maintain) is a simple-
method XML snippet)
2. Andrew's new pattern of attaching a groovy script to certain
permission strings to override the normal behavior of that string
3. Adrian's idea to create some new expression (possibly extend what
Andrew has done) and add functions to the permission string itself
(which might eventually have boolean logic and other things, and be a
little expression language of its own)
Does that sound about right?
When comparing these the big question for me is what will be easiest
for users to maintain, especially less technical users (ie non-
programmers, or I guess also programmers with little time and patience)?
In general I don't know if we'll EVER be able to come up with
something that allows non-technical users to easily configure dynamic
permissions to handle any possible situation. On the other hand, maybe
we can create something that handles most common cases (including both
functionality level and simple record level cases) and leave in
extension points so that it is possible to create more complicated
permission logic when needed.
In other words, however we do this we probably want some configurable
permissions that cover most stuff, and then extension mechanisms to
drop-down to lower level tools. That is the pattern used in pretty
much all of the OFBiz framework tools, and it would be good to apply
it here too.
A quick note on the extension mechanism: another pattern that has
emerged over time is to allow programmers to create custom logic and
put it somewhere that less-technical users can refer to. The reason
for this is that the custom stuff becomes a sort of tool that can be
documented and then used (but not manipulated) by less technical users
as part of their configuration. In other words the pattern would look
like the configuration part of things having the ability to reference
the custom logic part of things, and not the other way around (to make
it clear, that's a big distinction between #1 and #2 above, and I'm
not sure about #3 since it seems to mostly be meant to internalize
things in the permission string/expression instead of referring to
external stuff, but could certainly easily point explicitly to
external stuff).
Anyway, THANK YOU Adrian, this message is a breath of fresh air (part
of why I changed the subject line :) ) and it's great to discuss
actual issues and patterns and possible solutions.
-David
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 5/2/09, David E Jones <da...@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 that
> flexibility was better than ease in this case; and yes there
> is a creative way to invoke code attached to permissions,
> but that is a bit inflexible IMO since much permission logic
> involved multiple permissions... it's the artifact we
> want the code attached to not the permission itself)
I've been thinking about that aspect of it. If I understand correctly, here are two of the issues being addressed by the new security:
1. Permission checking is being done in scripts, so a programmer is required to change the permission checking logic. An ordinary systems administrator with no knowledge of mini-language would not be able to change how permissions are checked. The new permission string is supposed to make changes to permission checking easier for the non-programmer administrators.
2. Permission checking isn't consistent. Two similar branches of logic will check permissions in two different ways: one will check a permission string, and another will run a script. This is common in the UI versus the services called by the UI. A simple "has permission" check is done in the UI, and then the service invoked runs a script to check permissions.
I agree with you that substituting the permission service with a permission string is too inflexible.
One of the ideas I've been toying with is the idea of a permission expression. I started writing some code for that and was going to put it in Jira, but I decided to put it on the shelf until the dust settles from this thread.
Let's say we took Andrew's new permission string and gave it more oomph - where it could contain functions and such. (The expression language would be simple enough for common administrators to understand.) That could eliminate many of the permission checking scripts. In effect, the permission string becomes a mini-script. This mini-script could be used anywhere a permission string is being used now.
One of the problems I have with what has been proposed so far is that the permission string can be ambiguous when it comes to inserting parameters. For example, "update:example:${exampleId}" - what does that mean? There's no way to tell by looking at it. It would be preferable to have something like "update:example + relatedTo(exampleId)". That permission tells me something - it requires update:example permission and the user must be related to exampleId in some way.
I think permission expressions would solve both of the issues above.
-Adrian
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@hlmksw.com>.
Andrew Zeneski wrote:
> I never even considered such a thing when I started working on the
> process based designs because I was taking ease of migration into
> consideration. Changing from plain permission checks to a more process
> based permission string was large enough. However, my point is that if
> we are considering ways to change all the artifacts in OFBiz and how
> they deal with security it can be done with either of the two proposals.
I think the current feeling is, a completely different approach would be
acceptable if there is significant advantage to it. And if we do settle
on something completely different, then a migration service would be
mandatory.
-Adrian
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I should also note that in the process based system I have been
talking about we can easily follow similar patterns Adrian has
recommended. Service artifacts are one thing, as they usually only
relate to a single process. But in screens and other artifacts we
could "register" them with a process:
<screen ...>
<security process="party:contact" check="update/>
</screen>
This would populate a list of permissions available to the current
user for the process within that artifact and require the user to be
able to update in order for the screen to render. Then if we were
displaying a delete button another check could be run <security
check="delete"> to see if the delete button should be rendered.
This is technically no different than doing has-permission checks,
just doing so in a different XML format and instead of calling has-
permission many times it just gathers all permissions at once and then
permission checking is just handled from the screen's context.
I never even considered such a thing when I started working on the
process based designs because I was taking ease of migration into
consideration. Changing from plain permission checks to a more process
based permission string was large enough. However, my point is that if
we are considering ways to change all the artifacts in OFBiz and how
they deal with security it can be done with either of the two
proposals. With the process based designs it could just be done at a
later time.
Andrew
On May 5, 2009, at 2:04 PM, Andrew Zeneski wrote:
> Adrian,
>
> While this is fine when a artifact handles a specific "process" but
> what about when a screen (for example) like EditExample would be
> used for different processes? Often the same screen/form is used for
> create vs update; and even more often a user will have access to
> create but not update [everything].
>
> Also, an artifact (such as a screen) could contain multiple
> processes. A list screen for example may also include a delete
> button. However, with no explicit permission checks, the delete
> button will display for all users who have access to this artifact.
> So, you would still need to have explicit permission checks to see
> if the user has access to the delete button in this artifact.
>
> Andrew
>
>>> Permissions are hierarchical - each artifact inherits permissions
>>> from the artifact above it. This is very similar to what Andrew is
>>> trying to achieve, but it's different because the artifacts
>>> themselves control the security - there is no call to a permission
>>> service with a permission string.
>>>
>>> Here's what it might look like in ExampleScreens.xml:
>>>
>>> <screens xmlns:xsi="...">
>>> <security domain="framework:example:screen"/>
>>>
>>> <screen name="EditExample">
>>> <security domain="EditExample"/>
>>> ...
>>> </screen>
>>>
>>> </screens>
>>>
>>> Notice there are no explicit permission checks. Instead, each
>>> artifact has identified itself in the security domain.
>>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Adrian,
While this is fine when a artifact handles a specific "process" but
what about when a screen (for example) like EditExample would be used
for different processes? Often the same screen/form is used for create
vs update; and even more often a user will have access to create but
not update [everything].
Also, an artifact (such as a screen) could contain multiple processes.
A list screen for example may also include a delete button. However,
with no explicit permission checks, the delete button will display for
all users who have access to this artifact. So, you would still need
to have explicit permission checks to see if the user has access to
the delete button in this artifact.
Andrew
>> Permissions are hierarchical - each artifact inherits permissions
>> from the artifact above it. This is very similar to what Andrew is
>> trying to achieve, but it's different because the artifacts
>> themselves control the security - there is no call to a permission
>> service with a permission string.
>>
>> Here's what it might look like in ExampleScreens.xml:
>>
>> <screens xmlns:xsi="...">
>> <security domain="framework:example:screen"/>
>>
>> <screen name="EditExample">
>> <security domain="EditExample"/>
>> ...
>> </screen>
>>
>> </screens>
>>
>> Notice there are no explicit permission checks. Instead, each
>> artifact has identified itself in the security domain.
>
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I believe that no matter which method is used (process or artifact)
both would require similar access control logic to be implemented. I'm
not sure how this would look in the artifact system (Adrian can
comment on that), but in the process driven system there would be two
options.
1. For simple checking a record against a role table (take ContentRole
as an example for this discussion; note that content may or may not be
considered a simple check, that has yet to be discussed/designed) you
could define the process of update:content:data to use a common
RoleCheckingDa extension and set the allowed role type values. This
would remove the need for extra logic which would need to be
implemented in simple circumstances.
2. Custom DA logic would be attached; in the case of the
update:party:contact process, logic would be written to check first
the owner of the party vs the user attempting to run the process,
followed by checking to see if the user is an admin/owner of a group
which the party to update is a member of.
So to better answer your question, regardless of the type of system
used, this sort of access control would be available and part of the
application design. Based on what I have read so far, the artifact
driven model would require this logic to be implemented in multiple
places assuming you want the same control in multiple artifacts. Where
as in a process driven architecture you would connect this logic to
the process and then associate/check that process with multiple
artifacts.
Andrew
On May 4, 2009, at 2:39 PM, Al Byers wrote:
> Am I correct in thinking that artifact driven approach naturally
> integrates
> the concept of allowing inherited permission checking by roles, but
> in the
> process-driven approach we would have to use something like the
> RoleCheckingDa API extension? So if I want to give an administrator
> access
> to all records in their district schools, but not to all records in
> the
> state, I would just have to attach that person (or their role?) to the
> district and it would all be handled, but in the process-driven case
> I would
> have to make a call to perform that check?
>
> -Al
>
>
> On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <ad...@yahoo.com>
> wrote:
>
>>
>> I don't see us agreeing on anything. I'm saying each artifact is
>> responsible for its own security. You're saying security is defined
>> by a
>> process.
>>
>> If you were to view a collection of artifacts - each responsible
>> for its
>> own security - defining some kind of process-driven security, then
>> that
>> might be true.
>>
>> Applying your process-driven security design to the picture analogy
>> (from
>> what I have gathered so far from your design), it would be like
>> there is a
>> gatekeeper at the entrance to the picture. The gatekeeper says
>> "Adrian
>> intends to start the car, does he have permission to do that?" The
>> car has
>> no say in the matter. The gatekeeper controls everything.
>>
>> The inherent limitation to that design is, the gatekeeper has to
>> account
>> for every motive I might have in interacting with every artifact in
>> the
>> picture. That gatekeeper has a lot on its hands!
>>
>> I think it is simpler to have each artifact decide for itself what
>> Adrian
>> can or cannot do with it. I believe that was what David was trying to
>> express when he said "it's the artifact we want the code attached
>> to not the
>> permission itself."
>>
>> -Adrian
>>
>>
>> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: dev@ofbiz.apache.org
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <an...@hotwaxmedia.com> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>>
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@hlmksw.com>.
Agreed!
-Adrian
Andrew Zeneski wrote:
> We need to agree on terminology, authentication would refer to
> confirming a subject is who they say they are (checking user's
> name/password combination), where authorization would refer to granting
> access to something.
>
> What we having been discussing is re-designing the way ofbiz handles
> authorization. Authentication should be a completely different topic all
> together.
>
> On May 4, 2009, at 2:56 PM, Adrian Crum wrote:
>
>> So, no - the inheritance is not in user roles. However, user role
>> inheritance could be accommodated by the authentication mechanism.
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
We need to agree on terminology, authentication would refer to
confirming a subject is who they say they are (checking user's name/
password combination), where authorization would refer to granting
access to something.
What we having been discussing is re-designing the way ofbiz handles
authorization. Authentication should be a completely different topic
all together.
On May 4, 2009, at 2:56 PM, Adrian Crum wrote:
> So, no - the inheritance is not in user roles. However, user role
> inheritance could be accommodated by the authentication mechanism.
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@hlmksw.com>.
In the artifact-driven approach, the inheritance is from higher level
artifacts to lower level artifacts. So if I assign a user permission to
use a screen, that permission is inherited by all the artifacts the
screen contains. Contained artifacts can optionally override the
inherited permission.
So, no - the inheritance is not in user roles. However, user role
inheritance could be accommodated by the authentication mechanism.
-Adrian
Al Byers wrote:
> Am I correct in thinking that artifact driven approach naturally integrates
> the concept of allowing inherited permission checking by roles, but in the
> process-driven approach we would have to use something like the
> RoleCheckingDa API extension? So if I want to give an administrator access
> to all records in their district schools, but not to all records in the
> state, I would just have to attach that person (or their role?) to the
> district and it would all be handled, but in the process-driven case I would
> have to make a call to perform that check?
>
> -Al
>
>
> On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <ad...@yahoo.com> wrote:
>
>> I don't see us agreeing on anything. I'm saying each artifact is
>> responsible for its own security. You're saying security is defined by a
>> process.
>>
>> If you were to view a collection of artifacts - each responsible for its
>> own security - defining some kind of process-driven security, then that
>> might be true.
>>
>> Applying your process-driven security design to the picture analogy (from
>> what I have gathered so far from your design), it would be like there is a
>> gatekeeper at the entrance to the picture. The gatekeeper says "Adrian
>> intends to start the car, does he have permission to do that?" The car has
>> no say in the matter. The gatekeeper controls everything.
>>
>> The inherent limitation to that design is, the gatekeeper has to account
>> for every motive I might have in interacting with every artifact in the
>> picture. That gatekeeper has a lot on its hands!
>>
>> I think it is simpler to have each artifact decide for itself what Adrian
>> can or cannot do with it. I believe that was what David was trying to
>> express when he said "it's the artifact we want the code attached to not the
>> permission itself."
>>
>> -Adrian
>>
>>
>> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: dev@ofbiz.apache.org
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <an...@hotwaxmedia.com> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Al Byers <by...@automationgroups.com>.
Am I correct in thinking that artifact driven approach naturally integrates
the concept of allowing inherited permission checking by roles, but in the
process-driven approach we would have to use something like the
RoleCheckingDa API extension? So if I want to give an administrator access
to all records in their district schools, but not to all records in the
state, I would just have to attach that person (or their role?) to the
district and it would all be handled, but in the process-driven case I would
have to make a call to perform that check?
-Al
On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <ad...@yahoo.com> wrote:
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined by a
> process.
>
> If you were to view a collection of artifacts - each responsible for its
> own security - defining some kind of process-driven security, then that
> might be true.
>
> Applying your process-driven security design to the picture analogy (from
> what I have gathered so far from your design), it would be like there is a
> gatekeeper at the entrance to the picture. The gatekeeper says "Adrian
> intends to start the car, does he have permission to do that?" The car has
> no say in the matter. The gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to account
> for every motive I might have in interacting with every artifact in the
> picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what Adrian
> can or cannot do with it. I believe that was what David was trying to
> express when he said "it's the artifact we want the code attached to not the
> permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
>
> > From: Andrew Zeneski <an...@hotwaxmedia.com>
> > Subject: Re: Domain Based Security ( was re: Authz...)
> > To: dev@ofbiz.apache.org
> > Date: Sunday, May 3, 2009, 11:00 PM
> > I like to think of it more as process-driven permission vs
> > artifact driven permissions, because the "permission
> > string" is defined to match a specific process. Other
> > than that I think we finally agreed on something.. Ha! :)
> >
> > On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
> >
> > >
> > > --- On Sun, 5/3/09, Andrew Zeneski
> > <an...@hotwaxmedia.com> wrote:
> > >> The question I believe now is, which is better? I
> > >> personally think in terms of processes which is
> > why what I
> > >> proposed was all process based. However, artifact
> > based may
> > >> be more granular, but possibly too granular. If I
> > understand
> > >> this right, artifact based we could potentially
> > have
> > >> different access requirements for every single
> > >> form/screen/service/entity/etc; where in a process
> > based
> > >> system the developer would define the processes as
> > part of
> > >> the application and these processes could be
> > shared across
> > >> common artifacts (forms can share with screens
> > that share
> > >> with services, etc).
> > >>
> > >> Does this sound like a fair assessment?
> > >
> > > Yes it is. It boils down to permission-driven
> > permissions, versus artifact-driven permissions.
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
No you misunderstood me. I was referring to us agreeing in a previous
email that "it was a fair assessment". Hence the smiley. I think your
comparison here is correct. In the process driven model, the logic is
attached to the process, and the process is attached to various
artifacts. The "gatekeeper" indeed is the central holder of information.
However, I do believe your analogy is slightly off. Its more like
"Adrian wishes to start car X" the gatekeeper takes the information
from Adrian's "key" and says "Ok" or "Not Ok". The process is "start
car X", the credentials are the "ignition key".
Andrew
On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: dev@ofbiz.apache.org
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <an...@hotwaxmedia.com> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by David E Jones <da...@hotwaxmedia.com>.
Do you really think the intent of the people discussing this is to
confuse people, or even to convince people?
Let's be realistic about this... the subject here is a complicated one
and there are lots of different issues related to it. Some points are
coming up but I don't think we've even scratched the surface yet.
Heck, I don't think there has even been enough time for some people to
get over this enough personally and emotionally so that a totally
objective and rational conversation can even happen.
If you're wanting to use something then the best thing to do is write
up what you're wanting to do with it, and what you'd like to see in
the security functionality in OFBiz.
Back to the being realistic thing... again I don't think ANY of us has
thought this through thoroughly enough, including brainstorming to
explore options and then decision making to decide on it. Keep in mind
that if we choose something in a hasty way, it'll just not live as
long in the project. In other words, if there are still major issues
we'll all be wanting something different in the near future again
anyway. For example, I still haven't had a chance to write up some
security related things that are related to this and that have been
discussed over the years and that I think are important if we're going
to have an approach to security that will really meet the needs and
wants of users. I'm guessing there are others in the same boat.
I agree with Adam on this one, I don't think it's wise to expect the
conversation to settle down or for any of us to have a good thorough
chance to think it through in less than 2-4 weeks.
-David
On May 4, 2009, at 7:00 AM, Anil Patel wrote:
> Over last few days this discussion has changed subject few times.
> This is going more on lines of "confuse them if you cannot
> convenience".
>
> The new security system proposal document, implementation code and
> code demonstrating its use, been out for more then week, All big
> names in community have had chance to see it. I will rather discuss
> on list of items that are so bad about new security system (which is
> now in proposal status). If Andrew or others who like it cannot
> solve or disprove them then either we will know that its bad and
> cannot be used.
>
> I like the system and will like to use it.
>
> Regards
> Anil Patel
>
>
> On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
>>
>> I don't see us agreeing on anything. I'm saying each artifact is
>> responsible for its own security. You're saying security is defined
>> by a process.
>>
>> If you were to view a collection of artifacts - each responsible
>> for its own security - defining some kind of process-driven
>> security, then that might be true.
>>
>> Applying your process-driven security design to the picture analogy
>> (from what I have gathered so far from your design), it would be
>> like there is a gatekeeper at the entrance to the picture. The
>> gatekeeper says "Adrian intends to start the car, does he have
>> permission to do that?" The car has no say in the matter. The
>> gatekeeper controls everything.
>>
>> The inherent limitation to that design is, the gatekeeper has to
>> account for every motive I might have in interacting with every
>> artifact in the picture. That gatekeeper has a lot on its hands!
>>
>> I think it is simpler to have each artifact decide for itself what
>> Adrian can or cannot do with it. I believe that was what David was
>> trying to express when he said "it's the artifact we want the code
>> attached to not the permission itself."
>>
>> -Adrian
>>
>>
>> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: dev@ofbiz.apache.org
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <an...@hotwaxmedia.com> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>>
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Anil Patel <an...@hotwaxmedia.com>.
Vince,
Here are the documents
http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor
http://docs.ofbiz.org/display/~jaz/Permissions+By+Application
Thanks for asking for the document. I have example on "How successful
people been in confusing the community".
Regards
Anil Patel
On May 4, 2009, at 9:11 AM, Vince Clark wrote:
> Anil, you mentioned a document. Can you send out the link? I'm sure
> it is in these threads somewhere but with all the traffic on this
> topic I cannot seem to find a link to the doc.
>
> ----- Original Message -----
> From: "Anil Patel" <an...@hotwaxmedia.com>
> To: dev@ofbiz.apache.org
> Cc: "Anil Patel" <An...@hotwaxmedia.com>
> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
> Subject: Re: Domain Based Security ( was re: Authz...)
>
> Over last few days this discussion has changed subject few times. This
> is going more on lines of "confuse them if you cannot convenience".
>
> The new security system proposal document, implementation code and
> code demonstrating its use, been out for more then week, All big names
> in community have had chance to see it. I will rather discuss on list
> of items that are so bad about new security system (which is now in
> proposal status). If Andrew or others who like it cannot solve or
> disprove them then either we will know that its bad and cannot be
> used.
>
> I like the system and will like to use it.
>
> Regards
> Anil Patel
>
>
> On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
>>
>> I don't see us agreeing on anything. I'm saying each artifact is
>> responsible for its own security. You're saying security is defined
>> by a process.
>>
>> If you were to view a collection of artifacts - each responsible for
>> its own security - defining some kind of process-driven security,
>> then that might be true.
>>
>> Applying your process-driven security design to the picture analogy
>> (from what I have gathered so far from your design), it would be
>> like there is a gatekeeper at the entrance to the picture. The
>> gatekeeper says "Adrian intends to start the car, does he have
>> permission to do that?" The car has no say in the matter. The
>> gatekeeper controls everything.
>>
>> The inherent limitation to that design is, the gatekeeper has to
>> account for every motive I might have in interacting with every
>> artifact in the picture. That gatekeeper has a lot on its hands!
>>
>> I think it is simpler to have each artifact decide for itself what
>> Adrian can or cannot do with it. I believe that was what David was
>> trying to express when he said "it's the artifact we want the code
>> attached to not the permission itself."
>>
>> -Adrian
>>
>>
>> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: dev@ofbiz.apache.org
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <an...@hotwaxmedia.com> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>>
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: Domain Based Security ( was re: Authz...)
Posted by BJ Freeman <bj...@free-man.net>.
What I see so far is what the new system will do.
that is good
what I don't see is an equivalent document on how the old system handles
or does not handle the same situations. This would tie in with why the
need for the new system.
I also don't see, since this is a security system, any consideration
both for the old and new system as to its possible vulnerabilities to
hackers. How the new system will be better than the old system, doing
the job of keeping people out of areas that should not be in.
If there is going to be a honest to goodness review process, I believe
the above documents should be included.
Anil Patel sent the following on 5/4/2009 6:19 AM:
> Vince,
> Here are the documents
>
> http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor
> http://docs.ofbiz.org/display/~jaz/Permissions+By+Application
>
> Thanks for asking for the document. I have example on "How successful
> people been in confusing the community".
>
> Regards
> Anil Patel
>
>
> On May 4, 2009, at 9:11 AM, Vince Clark wrote:
>
>> Anil, you mentioned a document. Can you send out the link? I'm sure it
>> is in these threads somewhere but with all the traffic on this topic I
>> cannot seem to find a link to the doc.
>>
>> ----- Original Message -----
>> From: "Anil Patel" <an...@hotwaxmedia.com>
>> To: dev@ofbiz.apache.org
>> Cc: "Anil Patel" <An...@hotwaxmedia.com>
>> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
>> Subject: Re: Domain Based Security ( was re: Authz...)
>>
>> Over last few days this discussion has changed subject few times. This
>> is going more on lines of "confuse them if you cannot convenience".
>>
>> The new security system proposal document, implementation code and
>> code demonstrating its use, been out for more then week, All big names
>> in community have had chance to see it. I will rather discuss on list
>> of items that are so bad about new security system (which is now in
>> proposal status). If Andrew or others who like it cannot solve or
>> disprove them then either we will know that its bad and cannot be used.
>>
>> I like the system and will like to use it.
>>
>> Regards
>> Anil Patel
>>
>>
>> On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>>
>>>
>>> I don't see us agreeing on anything. I'm saying each artifact is
>>> responsible for its own security. You're saying security is defined
>>> by a process.
>>>
>>> If you were to view a collection of artifacts - each responsible for
>>> its own security - defining some kind of process-driven security,
>>> then that might be true.
>>>
>>> Applying your process-driven security design to the picture analogy
>>> (from what I have gathered so far from your design), it would be
>>> like there is a gatekeeper at the entrance to the picture. The
>>> gatekeeper says "Adrian intends to start the car, does he have
>>> permission to do that?" The car has no say in the matter. The
>>> gatekeeper controls everything.
>>>
>>> The inherent limitation to that design is, the gatekeeper has to
>>> account for every motive I might have in interacting with every
>>> artifact in the picture. That gatekeeper has a lot on its hands!
>>>
>>> I think it is simpler to have each artifact decide for itself what
>>> Adrian can or cannot do with it. I believe that was what David was
>>> trying to express when he said "it's the artifact we want the code
>>> attached to not the permission itself."
>>>
>>> -Adrian
>>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
>>> wrote:
>>>
>>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>>> To: dev@ofbiz.apache.org
>>>> Date: Sunday, May 3, 2009, 11:00 PM
>>>> I like to think of it more as process-driven permission vs
>>>> artifact driven permissions, because the "permission
>>>> string" is defined to match a specific process. Other
>>>> than that I think we finally agreed on something.. Ha! :)
>>>>
>>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>>> <an...@hotwaxmedia.com> wrote:
>>>>>> The question I believe now is, which is better? I
>>>>>> personally think in terms of processes which is
>>>> why what I
>>>>>> proposed was all process based. However, artifact
>>>> based may
>>>>>> be more granular, but possibly too granular. If I
>>>> understand
>>>>>> this right, artifact based we could potentially
>>>> have
>>>>>> different access requirements for every single
>>>>>> form/screen/service/entity/etc; where in a process
>>>> based
>>>>>> system the developer would define the processes as
>>>> part of
>>>>>> the application and these processes could be
>>>> shared across
>>>>>> common artifacts (forms can share with screens
>>>> that share
>>>>>> with services, etc).
>>>>>>
>>>>>> Does this sound like a fair assessment?
>>>>>
>>>>> Yes it is. It boils down to permission-driven
>>>> permissions, versus artifact-driven permissions.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
Re: Domain Based Security ( was re: Authz...)
Posted by Vince Clark <vc...@globalera.com>.
Anil, you mentioned a document. Can you send out the link? I'm sure it is in these threads somewhere but with all the traffic on this topic I cannot seem to find a link to the doc.
----- Original Message -----
From: "Anil Patel" <an...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
Cc: "Anil Patel" <An...@hotwaxmedia.com>
Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
Subject: Re: Domain Based Security ( was re: Authz...)
Over last few days this discussion has changed subject few times. This
is going more on lines of "confuse them if you cannot convenience".
The new security system proposal document, implementation code and
code demonstrating its use, been out for more then week, All big names
in community have had chance to see it. I will rather discuss on list
of items that are so bad about new security system (which is now in
proposal status). If Andrew or others who like it cannot solve or
disprove them then either we will know that its bad and cannot be used.
I like the system and will like to use it.
Regards
Anil Patel
On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: dev@ofbiz.apache.org
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <an...@hotwaxmedia.com> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Anil Patel <an...@hotwaxmedia.com>.
Over last few days this discussion has changed subject few times. This
is going more on lines of "confuse them if you cannot convenience".
The new security system proposal document, implementation code and
code demonstrating its use, been out for more then week, All big names
in community have had chance to see it. I will rather discuss on list
of items that are so bad about new security system (which is now in
proposal status). If Andrew or others who like it cannot solve or
disprove them then either we will know that its bad and cannot be used.
I like the system and will like to use it.
Regards
Anil Patel
On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: dev@ofbiz.apache.org
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <an...@hotwaxmedia.com> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> If I understand right where Adrian is going with this thread it is to
> just start with wanting to granular for flexibility r reasons and
> instead of having permissions that each screen/sevice/etc checks just
> have each screen/service/etc BE a permission of sorts. We wouldn't have
> any permission related configuration or code in the screens/services/etc
> except for a single attribute to flag whether permission is required or
> not (ie a require-permission flag), which we would want to be true by
> default. Now that the granularity issue is taken care of the next step
> is to build stuff on top of it to help manage the thousands of
> permissions that are now in the project... and THAT is where things get
> fun an interesting.
That's a close summary, but you forgot one thing - permission
inheritance. There won't be thousands of permissions - thanks to
inheritance. As far as I can tell, OFBiz out of the box wouldn't have
any more permissions than it has now.
-Adrian
Re: Domain Based Security ( was re: Authz...)
Posted by David E Jones <da...@hotwaxmedia.com>.
Sam,
That's an interesting article, and very relevant for some security
related changes we've done in recent months.
I was going to say that this discussion about a new security approach
doesn't have much to do with that article since this discussion is
really just all about how to configure and/or program access control
to different parts of the system and the intent is to improve ease of
use rather than tightness or thoroughness of security.
However, thinking about it more there are certain things that may
actually lead to tighter and more thorough security. For example, the
discussion about "Domain-Based Security" is heading in the direction
of externalizing 99% of the security configuration from the code. This
is an idea that has been discussed a few times over the year and I've
always found it interesting, but we really haven't had super-critical
issues with the permission configuration and code stuff so not much
has been done about it.
If I understand right where Adrian is going with this thread it is to
just start with wanting to granular for flexibility r reasons and
instead of having permissions that each screen/sevice/etc checks just
have each screen/service/etc BE a permission of sorts. We wouldn't
have any permission related configuration or code in the screens/
services/etc except for a single attribute to flag whether permission
is required or not (ie a require-permission flag), which we would want
to be true by default. Now that the granularity issue is taken care of
the next step is to build stuff on top of it to help manage the
thousands of permissions that are now in the project... and THAT is
where things get fun an interesting.
Anyway, I'm planning to write-up more of this as soon as I get the
time... hopefully in the next couple of days because I think this is
important... but I'm behind enough that people are actually writing me
directly and complaining that I haven't reviewed their stuff... in
other words it seems there are expectations about related to what they
think I should be doing and I haven't lived up to their dreams.
Oh, back to the first point: this approach might actually increase the
tightness and thoroughness of security because the default constraint
will change from allowing anything unless the screen/service/etc
checks for a permission, to allowing nothing unless the person
creating the screen/service/etc designates that no permission is
required, or the user has permission for that artifact (either to use
in general, or to use for a specific set of records).
So yes, this article IS actually relevant to the discussion.
-David
On May 4, 2009, at 5:35 AM, Sam Hamilton wrote:
> Not to get in the middle of this as to be honest I don't know enough
> for most of this thread to make sense but when I saw this article http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php
> it made me remember why everyone should be passionate about security
>
>
> On 04/05/2009 14:35, "Adrian Crum" <ad...@yahoo.com> wrote:
>
>
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: dev@ofbiz.apache.org
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <an...@hotwaxmedia.com> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Sam Hamilton <sa...@virtualvillage.com>.
Not to get in the middle of this as to be honest I don't know enough for most of this thread to make sense but when I saw this article http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php it made me remember why everyone should be passionate about security
On 04/05/2009 14:35, "Adrian Crum" <ad...@yahoo.com> wrote:
I don't see us agreeing on anything. I'm saying each artifact is responsible for its own security. You're saying security is defined by a process.
If you were to view a collection of artifacts - each responsible for its own security - defining some kind of process-driven security, then that might be true.
Applying your process-driven security design to the picture analogy (from what I have gathered so far from your design), it would be like there is a gatekeeper at the entrance to the picture. The gatekeeper says "Adrian intends to start the car, does he have permission to do that?" The car has no say in the matter. The gatekeeper controls everything.
The inherent limitation to that design is, the gatekeeper has to account for every motive I might have in interacting with every artifact in the picture. That gatekeeper has a lot on its hands!
I think it is simpler to have each artifact decide for itself what Adrian can or cannot do with it. I believe that was what David was trying to express when he said "it's the artifact we want the code attached to not the permission itself."
-Adrian
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> Subject: Re: Domain Based Security ( was re: Authz...)
> To: dev@ofbiz.apache.org
> Date: Sunday, May 3, 2009, 11:00 PM
> I like to think of it more as process-driven permission vs
> artifact driven permissions, because the "permission
> string" is defined to match a specific process. Other
> than that I think we finally agreed on something.. Ha! :)
>
> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>
> >
> > --- On Sun, 5/3/09, Andrew Zeneski
> <an...@hotwaxmedia.com> wrote:
> >> The question I believe now is, which is better? I
> >> personally think in terms of processes which is
> why what I
> >> proposed was all process based. However, artifact
> based may
> >> be more granular, but possibly too granular. If I
> understand
> >> this right, artifact based we could potentially
> have
> >> different access requirements for every single
> >> form/screen/service/entity/etc; where in a process
> based
> >> system the developer would define the processes as
> part of
> >> the application and these processes could be
> shared across
> >> common artifacts (forms can share with screens
> that share
> >> with services, etc).
> >>
> >> Does this sound like a fair assessment?
> >
> > Yes it is. It boils down to permission-driven
> permissions, versus artifact-driven permissions.
> >
> > -Adrian
> >
> >
> >
> >
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@yahoo.com>.
I don't see us agreeing on anything. I'm saying each artifact is responsible for its own security. You're saying security is defined by a process.
If you were to view a collection of artifacts - each responsible for its own security - defining some kind of process-driven security, then that might be true.
Applying your process-driven security design to the picture analogy (from what I have gathered so far from your design), it would be like there is a gatekeeper at the entrance to the picture. The gatekeeper says "Adrian intends to start the car, does he have permission to do that?" The car has no say in the matter. The gatekeeper controls everything.
The inherent limitation to that design is, the gatekeeper has to account for every motive I might have in interacting with every artifact in the picture. That gatekeeper has a lot on its hands!
I think it is simpler to have each artifact decide for itself what Adrian can or cannot do with it. I believe that was what David was trying to express when he said "it's the artifact we want the code attached to not the permission itself."
-Adrian
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> Subject: Re: Domain Based Security ( was re: Authz...)
> To: dev@ofbiz.apache.org
> Date: Sunday, May 3, 2009, 11:00 PM
> I like to think of it more as process-driven permission vs
> artifact driven permissions, because the "permission
> string" is defined to match a specific process. Other
> than that I think we finally agreed on something.. Ha! :)
>
> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>
> >
> > --- On Sun, 5/3/09, Andrew Zeneski
> <an...@hotwaxmedia.com> wrote:
> >> The question I believe now is, which is better? I
> >> personally think in terms of processes which is
> why what I
> >> proposed was all process based. However, artifact
> based may
> >> be more granular, but possibly too granular. If I
> understand
> >> this right, artifact based we could potentially
> have
> >> different access requirements for every single
> >> form/screen/service/entity/etc; where in a process
> based
> >> system the developer would define the processes as
> part of
> >> the application and these processes could be
> shared across
> >> common artifacts (forms can share with screens
> that share
> >> with services, etc).
> >>
> >> Does this sound like a fair assessment?
> >
> > Yes it is. It boils down to permission-driven
> permissions, versus artifact-driven permissions.
> >
> > -Adrian
> >
> >
> >
> >
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I like to think of it more as process-driven permission vs artifact
driven permissions, because the "permission string" is defined to
match a specific process. Other than that I think we finally agreed on
something.. Ha! :)
On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>> The question I believe now is, which is better? I
>> personally think in terms of processes which is why what I
>> proposed was all process based. However, artifact based may
>> be more granular, but possibly too granular. If I understand
>> this right, artifact based we could potentially have
>> different access requirements for every single
>> form/screen/service/entity/etc; where in a process based
>> system the developer would define the processes as part of
>> the application and these processes could be shared across
>> common artifacts (forms can share with screens that share
>> with services, etc).
>>
>> Does this sound like a fair assessment?
>
> Yes it is. It boils down to permission-driven permissions, versus
> artifact-driven permissions.
>
> -Adrian
>
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> The question I believe now is, which is better? I
> personally think in terms of processes which is why what I
> proposed was all process based. However, artifact based may
> be more granular, but possibly too granular. If I understand
> this right, artifact based we could potentially have
> different access requirements for every single
> form/screen/service/entity/etc; where in a process based
> system the developer would define the processes as part of
> the application and these processes could be shared across
> common artifacts (forms can share with screens that share
> with services, etc).
>
> Does this sound like a fair assessment?
Yes it is. It boils down to permission-driven permissions, versus artifact-driven permissions.
-Adrian
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Okay, so it seems that Adrian and I have a very similar idea. The only
major difference I see is one is artifact based and the other is
process based. In the artifact based system, each artifact needs to
register itself, and somehow the framework needs to know how to
process access control for each artifact. Each artifact still has
permissions, so it will check to see if the user has specific
permission(s) for the artifact. Access control logic is still
required, and the system will need to know how to process this for
each artifact. I'm not clear yet what that would look like, but so far
it doesn't sound much different.
In the process based system, instead of registering artifacts, the
developer registers process based strings with the system (in the
designs this is handled by seed data). Logic is attached to each
process string (or parent process string when parent/child share the
same logic). Authorization is handled per process by checking to see
if the user has "permission" to perform that process. Processes are
hierarchical (it appears the domain based system is as well) where a
user with access to the higher level of the hierarchy has implied
access to all the lower levels.
The question I believe now is, which is better? I personally think in
terms of processes which is why what I proposed was all process based.
However, artifact based may be more granular, but possibly too
granular. If I understand this right, artifact based we could
potentially have different access requirements for every single form/
screen/service/entity/etc; where in a process based system the
developer would define the processes as part of the application and
these processes could be shared across common artifacts (forms can
share with screens that share with services, etc).
Does this sound like a fair assessment?
Andrew
On May 3, 2009, at 10:22 PM, Adrian Crum wrote:
>
> Understood.
>
> If there is any interest in the design, and we start to flesh it
> out, I'm sure those scenarios could be presented and addressed.
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: dev@ofbiz.apache.org
>> Date: Sunday, May 3, 2009, 7:11 PM
>> Because no matter how we design security for the default
>> implementation in OFBiz there will always be some industry,
>> or business requirement that is not covered, there is no way
>> we can plan for every possible scenario. Thus, we need to
>> make sure there are simple ways to modify the default
>> behavior without having to intrude into the low level
>> functionality. This is one of the key issues I have been
>> trying to solve.
>>
>> On May 3, 2009, at 7:26 PM, Adrian Crum wrote:
>>
>>>>
>>>> My followup question will be, how do I customize
>> the access
>>>> logic for a specific client so that I can maintain
>> my own
>>>> logic in a private component and avoid problems
>> when
>>>> updating applications?
>>>
>>> Why would you want to do that? I can't think of a
>> reason why a security system would need to be changed.
>
>
>
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@yahoo.com>.
Understood.
If there is any interest in the design, and we start to flesh it out, I'm sure those scenarios could be presented and addressed.
-Adrian
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> Subject: Re: Domain Based Security ( was re: Authz...)
> To: dev@ofbiz.apache.org
> Date: Sunday, May 3, 2009, 7:11 PM
> Because no matter how we design security for the default
> implementation in OFBiz there will always be some industry,
> or business requirement that is not covered, there is no way
> we can plan for every possible scenario. Thus, we need to
> make sure there are simple ways to modify the default
> behavior without having to intrude into the low level
> functionality. This is one of the key issues I have been
> trying to solve.
>
> On May 3, 2009, at 7:26 PM, Adrian Crum wrote:
>
> >>
> >> My followup question will be, how do I customize
> the access
> >> logic for a specific client so that I can maintain
> my own
> >> logic in a private component and avoid problems
> when
> >> updating applications?
> >
> > Why would you want to do that? I can't think of a
> reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Because no matter how we design security for the default
implementation in OFBiz there will always be some industry, or
business requirement that is not covered, there is no way we can plan
for every possible scenario. Thus, we need to make sure there are
simple ways to modify the default behavior without having to intrude
into the low level functionality. This is one of the key issues I have
been trying to solve.
On May 3, 2009, at 7:26 PM, Adrian Crum wrote:
>>
>> My followup question will be, how do I customize the access
>> logic for a specific client so that I can maintain my own
>> logic in a private component and avoid problems when
>> updating applications?
>
> Why would you want to do that? I can't think of a reason why a
> security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> What you are describing here is very similar to the
> process-based authorization system which I proposed, the
> main differences is in my proposal everything is defined in
> a process [permission] string where this is based on
> artifacts. I think I need to understand this more, as I
> don't really see yet how it would work.
>
> You mention there is no permission-checking code, but you
> also mention that if the user has a specific permission then
> the screen is displayed. This is the confusing part to me
> right now. How does the "domain" know if a user
> has permission if there is no permission checking code?
I could have been more detailed in my description, so I apologize for the confusion. As far as implementation details are concerned, I intentionally left those out. The idea is to come up with a design for security first. Once that design is finalized, we can start working on implementation.
The security domain is just a representation of how OFBiz artifacts are laid out. It's like a picture of a car. You can't drive the picture, but you can drive the car.
Each artifact registers itself in the domain. I gave an example using a <security> element. Following the picture analogy, each <security> element adds something to the picture.
When a user attempts to access the artifact, the artifact takes its location in the security domain, and the user login (or whatever) and passes that information to an authentication mechanism. The authentication mechanism returns a set of permissions (create, update, delete, view, etc). The artifact takes those permissions and uses them accordingly (display a screen or return a permission error, display form data as text, or display form data as input fields).
To continue with the picture analogy, when the user enters the picture there will be artifacts there he/she can interact with. Let's say the picture includes a car, a boat, and lawn mower. The user's ability to start the engine on the car, boat, or lawn mower depends upon their "start engine" permission for each. In other words, the car says to the authentication mechanism, "I am a car. Give me the car permissions for user Adrian." The authentication mechanism returns a list of permissions. If one of those permissions is "start engine" I am able to start the car.
> Display a list of example records, for the records the user
> can update display the update button, for the records the
> user can delete show the delete button. For the records
> which the user does not have these permissions don't
> display the button.
Entities are no different than any other OFBiz artifact - they register themselves in the security domain. Entities could extend the <security> element with additional elements and attributes that define user permission on each record.
> When delete is pressed, we need to make sure the user
> really does have access to delete this record, how can we
> verify this?
The Delete button would know to appear only when the user has delete permission. If the permission doesn't exist, then the button doesn't appear.
> My followup question will be, how do I customize the access
> logic for a specific client so that I can maintain my own
> logic in a private component and avoid problems when
> updating applications?
Why would you want to do that? I can't think of a reason why a security system would need to be changed.
> For me these are the most important requirements (very
> granular control and ease of customizing without modifying
> files in the application).
I'm confident it will meet most security needs. The concept is not mine - it's modeled after Novell Netware's security (probably Windows too). I have yet to find a limitation in the ability to control user access to network resources.
-Adrian
Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
What you are describing here is very similar to the process-based
authorization system which I proposed, the main differences is in my
proposal everything is defined in a process [permission] string where
this is based on artifacts. I think I need to understand this more, as
I don't really see yet how it would work.
You mention there is no permission-checking code, but you also mention
that if the user has a specific permission then the screen is
displayed. This is the confusing part to me right now. How does the
"domain" know if a user has permission if there is no permission
checking code?
How does is the access control logic handled in this system? Could you
explain how to accomplish this example using this pattern:
Display a list of example records, for the records the user can update
display the update button, for the records the user can delete show
the delete button. For the records which the user does not have these
permissions don't display the button.
When delete is pressed, we need to make sure the user really does have
access to delete this record, how can we verify this?
My followup question will be, how do I customize the access logic for
a specific client so that I can maintain my own logic in a private
component and avoid problems when updating applications?
For me these are the most important requirements (very granular
control and ease of customizing without modifying files in the
application).
Andrew
On May 3, 2009, at 12:57 PM, Adrian Crum wrote:
>
> Take your comment - "it's the artifact we want the code attached to
> not the permission itself" - and combine that with Scott's
> suggestion to have a security-aware delegator, and you have a
> solution I proposed years ago: a domain-driven security system.
>
> In a domain-driven security system, each OFBiz artifact is
> responsible for handling security for itself. There is no explicit
> permission-checking code. Each OFBiz artifact identifies itself in a
> security domain. When a user tries to use that artifact, it checks
> the user's permissions against its own position in the domain.
>
> Using the Example component's EditExample screen as an example, here
> is what a security domain might look like:
>
> framework
> example
> screen
> EditExample (screen)
> EditExample (form)
>
> Permissions are hierarchical - each artifact inherits permissions
> from the artifact above it. This is very similar to what Andrew is
> trying to achieve, but it's different because the artifacts
> themselves control the security - there is no call to a permission
> service with a permission string.
>
> Here's what it might look like in ExampleScreens.xml:
>
> <screens xmlns:xsi="...">
> <security domain="framework:example:screen"/>
>
> <screen name="EditExample">
> <security domain="EditExample"/>
> ...
> </screen>
>
> </screens>
>
> Notice there are no explicit permission checks. Instead, each
> artifact has identified itself in the security domain.
>
> When the widget is run, each artifact checks the user's permissions
> against its own security domain. So, the EditExample screen would
> look for the framework:example:screen:EditExample" permissions and
> handle itself accordingly. (Andrew - this is why I suggested having
> permission checking code return all permissions for a context.)
>
> If a user has the access:framework:example:screen:EditExample
> permission, the screen will display.
>
> Let's take a look at what happens in the form widget. Here is what
> ExampleForms would look like:
>
> <form name="EditExample" type="single" target="updateExample"
> title="" default-map-name="example">
> <security domain="EditExample"/>
> ...
> </form>
>
> Again, when the widget is run, each artifact checks the user's
> permissions against its own security domain. So, the EditExample
> form would look for the
> framework:example:screen:EditExample:EditExample" permissions and
> handle itself accordingly.
>
> Let's say the user doesn't have any permissions for that context.
> Keep in mind permissions are hierarchical - so the form widget would
> work its way up the hierarchy to find permissions. If a user has the
> access:framework:example:screen:EditExample permission, the form
> will display plain text with no input fields. If the user has the
> update:framework:example:screen:EditExample permission, the form
> will provide input fields.
>
> Form fields could identify themselves in the security domain as well
> - so only the fields the user is permitted to access will appear.
>
> Service definitions and entities could identify themselves in the
> security domain in a similar way, and have similar permissions
> checking logic. Some examples:
>
> framework
> example
> service
> updateExample
>
> framework
> example
> entity
> Example
>
> The nice thing about this approach is that you could leverage the
> artifact gathering code to display the security domain as a tree -
> with permission checkboxes next to each "leaf." That would enable
> any administrator to manage user security easily.
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 5/2/09, David E Jones <da...@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 that
> flexibility was better than ease in this case; and yes there
> is a creative way to invoke code attached to permissions,
> but that is a bit inflexible IMO since much permission logic
> involved multiple permissions... it's the artifact we
> want the code attached to not the permission itself)
Take your comment - "it's the artifact we want the code attached to not the permission itself" - and combine that with Scott's suggestion to have a security-aware delegator, and you have a solution I proposed years ago: a domain-driven security system.
In a domain-driven security system, each OFBiz artifact is responsible for handling security for itself. There is no explicit permission-checking code. Each OFBiz artifact identifies itself in a security domain. When a user tries to use that artifact, it checks the user's permissions against its own position in the domain.
Using the Example component's EditExample screen as an example, here is what a security domain might look like:
framework
example
screen
EditExample (screen)
EditExample (form)
Permissions are hierarchical - each artifact inherits permissions from the artifact above it. This is very similar to what Andrew is trying to achieve, but it's different because the artifacts themselves control the security - there is no call to a permission service with a permission string.
Here's what it might look like in ExampleScreens.xml:
<screens xmlns:xsi="...">
<security domain="framework:example:screen"/>
<screen name="EditExample">
<security domain="EditExample"/>
...
</screen>
</screens>
Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain.
When the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample screen would look for the framework:example:screen:EditExample" permissions and handle itself accordingly. (Andrew - this is why I suggested having permission checking code return all permissions for a context.)
If a user has the access:framework:example:screen:EditExample permission, the screen will display.
Let's take a look at what happens in the form widget. Here is what ExampleForms would look like:
<form name="EditExample" type="single" target="updateExample" title="" default-map-name="example">
<security domain="EditExample"/>
...
</form>
Again, when the widget is run, each artifact checks the user's permissions against its own security domain. So, the EditExample form would look for the framework:example:screen:EditExample:EditExample" permissions and handle itself accordingly.
Let's say the user doesn't have any permissions for that context. Keep in mind permissions are hierarchical - so the form widget would work its way up the hierarchy to find permissions. If a user has the access:framework:example:screen:EditExample permission, the form will display plain text with no input fields. If the user has the update:framework:example:screen:EditExample permission, the form will provide input fields.
Form fields could identify themselves in the security domain as well - so only the fields the user is permitted to access will appear.
Service definitions and entities could identify themselves in the security domain in a similar way, and have similar permissions checking logic. Some examples:
framework
example
service
updateExample
framework
example
entity
Example
The nice thing about this approach is that you could leverage the artifact gathering code to display the security domain as a tree - with permission checkboxes next to each "leaf." That would enable any administrator to manage user security easily.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by David E Jones <da...@hotwaxmedia.com>.
This seemed like as good a message to respond to as any... nice thread
though!
Since revisionist history seems popular in this thread here is my own:
One day I saw a Jira issue that pointed to some big documents that
were in someone's personal space on confluence, and pages I had not
seen referenced before. Unfortunately posting something to confluence
doesn't put it in front of very many eyes (ie only those who watch the
regular updates), more on that below. The next day I saw some code
going in, and then more and more. Being stuck traveling at the time I
didn't have time to review or comment, and WHAM! there the code was
and the ONLY to get any changes to it at that point are to complain
and fight like hell... being too tired for that and too frustrated
with that and various other things, I just added my comments to a
confluence page of my own, and this one is in the open wiki and not in
my personal space:
http://docs.ofbiz.org/display/OFBIZ/Notes+on+New+Security+Model
How many people saw it? Well, no matter, if you are interested please
take a look now.
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 that flexibility was better than ease in this
case; and yes there is a creative way to invoke code attached to
permissions, but that is a bit inflexible IMO since much permission
logic involved multiple permissions... it's the artifact we want the
code attached to not the permission itself), plus will cause migration
pain for those updating. I'm not against change and progress... unless
it is change only for the sake of change and founded on someone's
subjective opinion of what is better and easier.
I see no side-by-side comparisons or concrete improvements or even
presentation of non-subjective issues to resolve (ie "this is
prettier, and easier", that's subjective), just a bunch of stuff in
the documents that is (in my subjective view) just a bunch of BS that
could have been generated by a "business software BS generator". To
find some great examples of those, search on google for "bs
generator", some fun results include:
http://www.atrixnet.com/bs-generator.html
http://www.erikandanna.com/Humor/bullshit_generator.htm
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. If you think that's harsh then bash me like you've bashed
Adrian. Don't worry... go for it! I happen to have a button with the
letters "delete" on it, and I've been using it more and more lately.
As for how to move forward? How about we allow development to go on as
desired, and we'll discuss and modify best practices over time. I will
revert the changes to the example component (in the spirit of Commit-
Then-Review that some are so fond of... well there's my review and a
commit to boot!). BTW, thanks Andrew for isolating those in a single
commit. For examples going forward whle this is still up in the air,
examples of use new artifacts can be added (ie new service, screen,
etc), or a patch can be kept on a jira issue for those who want to try
it out. Once we have decided on best practices moving forward, then we
can change the example component. Not sure how people want to move
forward, but for now I have attached the patch here (note that this
can also be produced with a "svn diff -r 770083:r770408 >
AuthzExampleComponentSupport.patch" from the ofbiz/framework/exmaple
directory):
https://issues.apache.org/jira/browse/OFBIZ-2383
For other components let's not be too hasty. I won't get into a commit
war over the example component, but for the rest I'll gladly do so
since I think these changes have a negative ROI and this whole thing
has turned into a big old chest-thumping mess. That being the case,
sorry for joining in and thumping my own chest.
Hopefully we can discuss some security objectives and common cases we
want to support, and then evaluate this new proposed approach against
them and/or establish a new approach based on this. There definitely
ARE areas where it is currently cumbersome to implement specific
security related requirements.
-David
On May 1, 2009, at 10:00 PM, Andrew Zeneski wrote:
> In the past, what 8 years that I have been working on OFBiz, not
> once have I had the masochistic urge to work on something which did
> not already have some sort of design. Never will you fine me
> wishing to refactor something without having the requirements
> already known. So, you will never find me coming to the table empty
> handed, and that is exactly what this sort of "request" is asking.
>
> Nor, do I want to review and discuss with someone an idea until they
> have their thoughts put together. So, what you can expect from me
> now, in the past and in the future is exactly your first statement.
> "Here is my design, what do you think..."
>
>
> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>
>>
>> It's not the same! There is a big difference between "Here's my
>> design, what do you think?" and "I'm interested in refactoring the
>> security framework. Could you help me with the design?"
>>
>> -Adrian
>>
>> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>>
>>> From: Scott Gray <sc...@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 at least we have a starting point.
>>>
>>> Regards
>>> Scott
>>>
>>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>>
>>>>
>>>> How about we start over and collaborate on a design?
>>> Is that so much
>>>> different?
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> --- On Fri, 5/1/09, Scott Gray
>>> <sc...@hotwaxmedia.com> wrote:
>>>>
>>>>> From: Scott Gray
>>> <sc...@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
>>>>> 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.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>>>>
>>>>>>
>>>>>> --- On Fri, 5/1/09, Anil Patel
>>>>> <an...@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 only started after Adrian and
>>> Jacques
>>>>> showed
>>>>>>> interest by commenting on the page.
>>>>>>
>>>>>> The only interest I showed was that I agreed
>>> that
>>>>> OFBiz security could use improvement, and I
>>> suggested he use
>>>>> a third party library. I did not endorse or
>>> approve of his
>>>>> design.
>>>>>>
>>>>>>> Andrew has been actively explaining his
>>> idea all
>>>>> this time.
>>>>>>
>>>>>> As I demonstrated in another reply, no he did
>>> not.
>>>>> Only a few days went by between introducing the
>>> idea and
>>>>> committing code.
>>>>>>
>>>>>>> The work done till date is not blocking
>>> anybody,
>>>>> old
>>>>>>> security system is still in place. New
>>> system is
>>>>> implemented
>>>>>>> in example component so its lot easy for
>>> him to
>>>>> explain and
>>>>>>> people to understand.
>>>>>>
>>>>>> What if the new work is a bad design? How will
>>> we know
>>>>> that until everyone has had time to evaluate it?
>>>>>>
>>>>>>> People have different ways of working in
>>>>> community, Joe is
>>>>>>> committer still all the time he creates
>>> Jira issue
>>>>> and
>>>>>>> uploads his patch and most of time its
>>> somebody
>>>>> else who
>>>>>>> does commits, but that's his way of
>>> working.
>>>>> If we
>>>>>>> don't do what Joe does then why should
>>> Andrew
>>>>> do what
>>>>>>> Adrian does.
>>>>>>
>>>>>> As far as I know, Joe submits patches for
>>> things he
>>>>> doesn't have commit rights to.
>>>>>>
>>>>>>> I don't see any reason why we should
>>> start
>>>>> over.
>>>>>>
>>>>>> Do you see a reason why we shouldn't? Will
>>> the
>>>>> project suffer immensely if we pause and wait for
>>> others to
>>>>> comment? Is there some catastrophe looming that
>>> requires us
>>>>> to rush this through?
>>>>>>
>>>>>>> All
>>>>>>> the time we talk about making things easy
>>> so
>>>>> people will
>>>>>>> contribute, Why do you want to resist a
>>> seasoned
>>>>> contributer
>>>>>>> for working. I'll rather have expect
>>> community
>>>>> will
>>>>>>> support. All the time he has been asking
>>> people to
>>>>> tell him
>>>>>>> suggestions, wish list etc. Why not
>>> support him
>>>>> and get more
>>>>>>> out of him instead.
>>>>>>
>>>>>> If we can't invite the community to
>>> participate -
>>>>> as I suggested - then that only proves what I
>>> suspect - that
>>>>> this is a design that is being foisted on the
>>> community.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Jacques Le Roux <ja...@les7arts.com>.
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)
http://docs.ofbiz.org/x/bR4 (David's comments)
http://docs.ofbiz.org/display/OFBTECH/OFBiz+security (Doc on security so far)
BTW, we should take care of updating the last link.
Jacques
From: "Andrew Zeneski" <an...@hotwaxmedia.com>
> Adrian,
>
> Thank you very much for your comments. Minor point, you misread what I
> said. I said "NOT ONCE have I had the masochistic urge to work on
> something which did not already have some sort of design"... meaning
> everything has had some sort of design even if its some sticky notes
> on my wall, or a drawing on the whiteboard describing a
> ContentMapFacade, or a full blown document like I put together in this
> case. Also, it is my experience that a prototype of some sort is often
> a good way to prove the concept and something I am often asked to
> provide.
>
> While I have nothing against working as in a community, hell isn't
> that why OFBiz is here? This is my way of working with the community,
> what you will see are proposals and prototypes like what you have
> right now. I have NEVER implied that my designs or implementations
> were ever superior, however I don't see any other proposals on the
> table right now. If was trying to avoid discussing and collaborating,
> you would hear nothing about it from me except for a some commits and
> more than half the applications would be finished already...
>
> Now that everyone has expressed themselves, I think we can move on to
> business. What we have in front of us today is a proposal and
> prototype of a new security enhancement which is really based several
> things. We have an API which can be implemented for various different
> methods of authorization. The design was careful to not require
> anything specific to the internal security functionality. I do plan to
> implement a Crowd version of this as well, which would end up being a
> hybrid LDAP via Crowd/OFBiz combination. A pure LDAP implementation
> can be developed as well, which is one thing I was certain you would
> be interested in.
>
> The designs are really very similar to those we discussed 2 years ago
> when the PermissionService stuff was implemented. For some reason
> however I let others influence my decision at that time and let it go.
> There was some discussion about more granular permissions for forums
> and I would personally like to implement much more granular
> permissions in Project Manager and SFA applications. Which is were
> this entire effort branched from.
>
> I find it frustrating that authorization is handled in so many
> different places and looking at it now, to me it looks like a total
> mess. I will want to customize the access control for the applications
> we use internally, no I need to. I don't want to patch or extend
> service definitions b/c that makes upgrading all that much more
> complicated. Finally, I want one single API which I can use throughout
> the system to check permission.
>
> I wrote a security prototype using JSecurity and Hibernate to get a
> feel for some other tools. Even considered integrating JSecurity into
> OFBiz. However, the major limitation to that API is that all
> permissions are loaded for a user when they authenticate. So, if we
> were to write custom logic to handle very granular permissions we
> could end up with millions or billions of permissions loaded into
> memory. This didn't seem scalable.
>
> I spent about a week writing down thoughts about what an ideal
> authorization scheme would look like. I compared that to what we have
> and came up with the designs that were posted last Friday.
>
> Last weekend, a received a few comments regarding the designs posted
> in Confluence and on Monday when I heard nothing more decided to start
> working on implementing the API. Only took a few hours, but after
> another day or so of testing I was then able to check it in for
> comments.
>
> The main points in this design is that is brings about a new
> permission format which provides a simple way to create very granular
> permissions. This is actually the main draw, the whole API is based
> around the permission format. Next, the pains in keeping up with <has-
> permission>, <permission-service> the various different things which
> need to be called. The PermissionService implementation never became
> the "center". It was always still tied with the Security object, so
> now I think its time to address it completely and really centralize
> authorization.
>
> Now that there is proposal and a prototype, I would like to know if
> there are any requirements I did not account for. Like the
> findMatchingPermissions() idea was fantastic, and that is now part of
> the API and document. Let's review what we have and see what can make
> it better, but let's do it quickly...
>
> Andrew
>
> p.s. The one thing I don't care about is the fact that this is big and
> will require a lot of work, one of the reasons I am trying to move
> quickly on this is so that *I* have enough time to complete it. I'm
> not expecting everyone to jump in and help, and I don't want to leave
> it half done.
>
>
> On May 2, 2009, at 12:35 AM, Adrian Crum wrote:
>
>>
>> Understood.
>>
>> I remember sitting next to you at the developer's conference, and
>> watching you work. I experienced firsthand your "masochistic urge to
>> work on something which did not already have some sort of design." I
>> asked you for help, and you gave me links that pointed me right to
>> the answer. I really appreciated that. I admire you and I respect
>> you. Please understand that.
>>
>> Before I got involved with OFBiz I worked as an independent
>> programmer - I didn't have to answer to anyone. I could do my own
>> thing. Like you, I had the "masochistic urge to work on something
>> which did not already have some sort of design." I didn't consult
>> with anyone - I just came up with a design and wrote the code for it.
>>
>> Working with the OFBiz community has taught me the value of
>> community. It has changed my ways. I started off with suggesting my
>> "superior designs" (that I emailed to David, and I am embarrassed to
>> read today) and they were critiqued, in a stern yet polite way. Yet
>> I accepted those critiques. In the years that followed, David and I
>> would disagree about many things, but I never ignored his advice or
>> his opinions - I would always consider them carefully.
>>
>> So that's all I'm suggesting now. Please understand that you are
>> respected for who you are - one of the founders of the project.
>> Please understand that you are respected for your talent. But also,
>> please understand that we are a community.
>>
>> I want to help with this effort. There is nothing that would satisfy
>> me more than all of us working together on the refactoring of OFBiz
>> security. All I ask is that we back off for a little while and let
>> the community offer their comments, suggestions, and recommendations
>> - even if it means discarding "superior designs." Together, we can
>> take those comments, suggestions, and recommendations, and use them
>> to redesign OFBiz security in a way that will meet the needs of the
>> community and impress the world at large.
>>
>> -Adrian
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Adrian,
Thank you very much for your comments. Minor point, you misread what I
said. I said "NOT ONCE have I had the masochistic urge to work on
something which did not already have some sort of design"... meaning
everything has had some sort of design even if its some sticky notes
on my wall, or a drawing on the whiteboard describing a
ContentMapFacade, or a full blown document like I put together in this
case. Also, it is my experience that a prototype of some sort is often
a good way to prove the concept and something I am often asked to
provide.
While I have nothing against working as in a community, hell isn't
that why OFBiz is here? This is my way of working with the community,
what you will see are proposals and prototypes like what you have
right now. I have NEVER implied that my designs or implementations
were ever superior, however I don't see any other proposals on the
table right now. If was trying to avoid discussing and collaborating,
you would hear nothing about it from me except for a some commits and
more than half the applications would be finished already...
Now that everyone has expressed themselves, I think we can move on to
business. What we have in front of us today is a proposal and
prototype of a new security enhancement which is really based several
things. We have an API which can be implemented for various different
methods of authorization. The design was careful to not require
anything specific to the internal security functionality. I do plan to
implement a Crowd version of this as well, which would end up being a
hybrid LDAP via Crowd/OFBiz combination. A pure LDAP implementation
can be developed as well, which is one thing I was certain you would
be interested in.
The designs are really very similar to those we discussed 2 years ago
when the PermissionService stuff was implemented. For some reason
however I let others influence my decision at that time and let it go.
There was some discussion about more granular permissions for forums
and I would personally like to implement much more granular
permissions in Project Manager and SFA applications. Which is were
this entire effort branched from.
I find it frustrating that authorization is handled in so many
different places and looking at it now, to me it looks like a total
mess. I will want to customize the access control for the applications
we use internally, no I need to. I don't want to patch or extend
service definitions b/c that makes upgrading all that much more
complicated. Finally, I want one single API which I can use throughout
the system to check permission.
I wrote a security prototype using JSecurity and Hibernate to get a
feel for some other tools. Even considered integrating JSecurity into
OFBiz. However, the major limitation to that API is that all
permissions are loaded for a user when they authenticate. So, if we
were to write custom logic to handle very granular permissions we
could end up with millions or billions of permissions loaded into
memory. This didn't seem scalable.
I spent about a week writing down thoughts about what an ideal
authorization scheme would look like. I compared that to what we have
and came up with the designs that were posted last Friday.
Last weekend, a received a few comments regarding the designs posted
in Confluence and on Monday when I heard nothing more decided to start
working on implementing the API. Only took a few hours, but after
another day or so of testing I was then able to check it in for
comments.
The main points in this design is that is brings about a new
permission format which provides a simple way to create very granular
permissions. This is actually the main draw, the whole API is based
around the permission format. Next, the pains in keeping up with <has-
permission>, <permission-service> the various different things which
need to be called. The PermissionService implementation never became
the "center". It was always still tied with the Security object, so
now I think its time to address it completely and really centralize
authorization.
Now that there is proposal and a prototype, I would like to know if
there are any requirements I did not account for. Like the
findMatchingPermissions() idea was fantastic, and that is now part of
the API and document. Let's review what we have and see what can make
it better, but let's do it quickly...
Andrew
p.s. The one thing I don't care about is the fact that this is big and
will require a lot of work, one of the reasons I am trying to move
quickly on this is so that *I* have enough time to complete it. I'm
not expecting everyone to jump in and help, and I don't want to leave
it half done.
On May 2, 2009, at 12:35 AM, Adrian Crum wrote:
>
> Understood.
>
> I remember sitting next to you at the developer's conference, and
> watching you work. I experienced firsthand your "masochistic urge to
> work on something which did not already have some sort of design." I
> asked you for help, and you gave me links that pointed me right to
> the answer. I really appreciated that. I admire you and I respect
> you. Please understand that.
>
> Before I got involved with OFBiz I worked as an independent
> programmer - I didn't have to answer to anyone. I could do my own
> thing. Like you, I had the "masochistic urge to work on something
> which did not already have some sort of design." I didn't consult
> with anyone - I just came up with a design and wrote the code for it.
>
> Working with the OFBiz community has taught me the value of
> community. It has changed my ways. I started off with suggesting my
> "superior designs" (that I emailed to David, and I am embarrassed to
> read today) and they were critiqued, in a stern yet polite way. Yet
> I accepted those critiques. In the years that followed, David and I
> would disagree about many things, but I never ignored his advice or
> his opinions - I would always consider them carefully.
>
> So that's all I'm suggesting now. Please understand that you are
> respected for who you are - one of the founders of the project.
> Please understand that you are respected for your talent. But also,
> please understand that we are a community.
>
> I want to help with this effort. There is nothing that would satisfy
> me more than all of us working together on the refactoring of OFBiz
> security. All I ask is that we back off for a little while and let
> the community offer their comments, suggestions, and recommendations
> - even if it means discarding "superior designs." Together, we can
> take those comments, suggestions, and recommendations, and use them
> to redesign OFBiz security in a way that will meet the needs of the
> community and impress the world at large.
>
> -Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
Understood.
I remember sitting next to you at the developer's conference, and watching you work. I experienced firsthand your "masochistic urge to work on something which did not already have some sort of design." I asked you for help, and you gave me links that pointed me right to the answer. I really appreciated that. I admire you and I respect you. Please understand that.
Before I got involved with OFBiz I worked as an independent programmer - I didn't have to answer to anyone. I could do my own thing. Like you, I had the "masochistic urge to work on something which did not already have some sort of design." I didn't consult with anyone - I just came up with a design and wrote the code for it.
Working with the OFBiz community has taught me the value of community. It has changed my ways. I started off with suggesting my "superior designs" (that I emailed to David, and I am embarrassed to read today) and they were critiqued, in a stern yet polite way. Yet I accepted those critiques. In the years that followed, David and I would disagree about many things, but I never ignored his advice or his opinions - I would always consider them carefully.
So that's all I'm suggesting now. Please understand that you are respected for who you are - one of the founders of the project. Please understand that you are respected for your talent. But also, please understand that we are a community.
I want to help with this effort. There is nothing that would satisfy me more than all of us working together on the refactoring of OFBiz security. All I ask is that we back off for a little while and let the community offer their comments, suggestions, and recommendations - even if it means discarding "superior designs." Together, we can take those comments, suggestions, and recommendations, and use them to redesign OFBiz security in a way that will meet the needs of the community and impress the world at large.
-Adrian
--- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: dev@ofbiz.apache.org
> Date: Friday, May 1, 2009, 9:00 PM
> In the past, what 8 years that I have been working on OFBiz,
> not once
> have I had the masochistic urge to work on something which
> did not
> already have some sort of design. Never will you fine me
> wishing to
> refactor something without having the requirements already
> known. So,
> you will never find me coming to the table empty handed,
> and that is
> exactly what this sort of "request" is asking.
>
> Nor, do I want to review and discuss with someone an idea
> until they
> have their thoughts put together. So, what you can expect
> from me now,
> in the past and in the future is exactly your first
> statement. "Here
> is my design, what do you think..."
>
>
> On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>
> >
> > It's not the same! There is a big difference
> between "Here's my
> > design, what do you think?" and "I'm
> interested in refactoring the
> > security framework. Could you help me with the
> design?"
> >
> > -Adrian
> >
> > --- On Fri, 5/1/09, Scott Gray
> <sc...@hotwaxmedia.com> wrote:
> >
> >> From: Scott Gray
> <sc...@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 at least we have a starting
> point.
> >>
> >> Regards
> >> Scott
> >>
> >> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
> >>
> >>>
> >>> How about we start over and collaborate on a
> design?
> >> Is that so much
> >>> different?
> >>>
> >>> -Adrian
> >>>
> >>>
> >>> --- On Fri, 5/1/09, Scott Gray
> >> <sc...@hotwaxmedia.com> wrote:
> >>>
> >>>> From: Scott Gray
> >> <sc...@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
> >>>> 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.
> >>>>
> >>>> Regards
> >>>> Scott
> >>>>
> >>>> On 2/05/2009, at 2:19 PM, Adrian Crum
> wrote:
> >>>>
> >>>>>
> >>>>> --- On Fri, 5/1/09, Anil Patel
> >>>> <an...@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 only started after
> Adrian and
> >> Jacques
> >>>> showed
> >>>>>> interest by commenting on the
> page.
> >>>>>
> >>>>> The only interest I showed was that I
> agreed
> >> that
> >>>> OFBiz security could use improvement, and
> I
> >> suggested he use
> >>>> a third party library. I did not endorse
> or
> >> approve of his
> >>>> design.
> >>>>>
> >>>>>> Andrew has been actively
> explaining his
> >> idea all
> >>>> this time.
> >>>>>
> >>>>> As I demonstrated in another reply, no
> he did
> >> not.
> >>>> Only a few days went by between
> introducing the
> >> idea and
> >>>> committing code.
> >>>>>
> >>>>>> The work done till date is not
> blocking
> >> anybody,
> >>>> old
> >>>>>> security system is still in place.
> New
> >> system is
> >>>> implemented
> >>>>>> in example component so its lot
> easy for
> >> him to
> >>>> explain and
> >>>>>> people to understand.
> >>>>>
> >>>>> What if the new work is a bad design?
> How will
> >> we know
> >>>> that until everyone has had time to
> evaluate it?
> >>>>>
> >>>>>> People have different ways of
> working in
> >>>> community, Joe is
> >>>>>> committer still all the time he
> creates
> >> Jira issue
> >>>> and
> >>>>>> uploads his patch and most of time
> its
> >> somebody
> >>>> else who
> >>>>>> does commits, but that's his
> way of
> >> working.
> >>>> If we
> >>>>>> don't do what Joe does then
> why should
> >> Andrew
> >>>> do what
> >>>>>> Adrian does.
> >>>>>
> >>>>> As far as I know, Joe submits patches
> for
> >> things he
> >>>> doesn't have commit rights to.
> >>>>>
> >>>>>> I don't see any reason why we
> should
> >> start
> >>>> over.
> >>>>>
> >>>>> Do you see a reason why we
> shouldn't? Will
> >> the
> >>>> project suffer immensely if we pause and
> wait for
> >> others to
> >>>> comment? Is there some catastrophe looming
> that
> >> requires us
> >>>> to rush this through?
> >>>>>
> >>>>>> All
> >>>>>> the time we talk about making
> things easy
> >> so
> >>>> people will
> >>>>>> contribute, Why do you want to
> resist a
> >> seasoned
> >>>> contributer
> >>>>>> for working. I'll rather have
> expect
> >> community
> >>>> will
> >>>>>> support. All the time he has been
> asking
> >> people to
> >>>> tell him
> >>>>>> suggestions, wish list etc. Why
> not
> >> support him
> >>>> and get more
> >>>>>> out of him instead.
> >>>>>
> >>>>> If we can't invite the community
> to
> >> participate -
> >>>> as I suggested - then that only proves
> what I
> >> suspect - that
> >>>> this is a design that is being foisted on
> the
> >> community.
> >>>>>
> >>>>> -Adrian
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
In the past, what 8 years that I have been working on OFBiz, not once
have I had the masochistic urge to work on something which did not
already have some sort of design. Never will you fine me wishing to
refactor something without having the requirements already known. So,
you will never find me coming to the table empty handed, and that is
exactly what this sort of "request" is asking.
Nor, do I want to review and discuss with someone an idea until they
have their thoughts put together. So, what you can expect from me now,
in the past and in the future is exactly your first statement. "Here
is my design, what do you think..."
On May 1, 2009, at 10:56 PM, Adrian Crum wrote:
>
> It's not the same! There is a big difference between "Here's my
> design, what do you think?" and "I'm interested in refactoring the
> security framework. Could you help me with the design?"
>
> -Adrian
>
> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>
>> From: Scott Gray <sc...@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 at least we have a starting point.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>
>>>
>>> How about we start over and collaborate on a design?
>> Is that so much
>>> different?
>>>
>>> -Adrian
>>>
>>>
>>> --- On Fri, 5/1/09, Scott Gray
>> <sc...@hotwaxmedia.com> wrote:
>>>
>>>> From: Scott Gray
>> <sc...@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
>>>> 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.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> --- On Fri, 5/1/09, Anil Patel
>>>> <an...@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 only started after Adrian and
>> Jacques
>>>> showed
>>>>>> interest by commenting on the page.
>>>>>
>>>>> The only interest I showed was that I agreed
>> that
>>>> OFBiz security could use improvement, and I
>> suggested he use
>>>> a third party library. I did not endorse or
>> approve of his
>>>> design.
>>>>>
>>>>>> Andrew has been actively explaining his
>> idea all
>>>> this time.
>>>>>
>>>>> As I demonstrated in another reply, no he did
>> not.
>>>> Only a few days went by between introducing the
>> idea and
>>>> committing code.
>>>>>
>>>>>> The work done till date is not blocking
>> anybody,
>>>> old
>>>>>> security system is still in place. New
>> system is
>>>> implemented
>>>>>> in example component so its lot easy for
>> him to
>>>> explain and
>>>>>> people to understand.
>>>>>
>>>>> What if the new work is a bad design? How will
>> we know
>>>> that until everyone has had time to evaluate it?
>>>>>
>>>>>> People have different ways of working in
>>>> community, Joe is
>>>>>> committer still all the time he creates
>> Jira issue
>>>> and
>>>>>> uploads his patch and most of time its
>> somebody
>>>> else who
>>>>>> does commits, but that's his way of
>> working.
>>>> If we
>>>>>> don't do what Joe does then why should
>> Andrew
>>>> do what
>>>>>> Adrian does.
>>>>>
>>>>> As far as I know, Joe submits patches for
>> things he
>>>> doesn't have commit rights to.
>>>>>
>>>>>> I don't see any reason why we should
>> start
>>>> over.
>>>>>
>>>>> Do you see a reason why we shouldn't? Will
>> the
>>>> project suffer immensely if we pause and wait for
>> others to
>>>> comment? Is there some catastrophe looming that
>> requires us
>>>> to rush this through?
>>>>>
>>>>>> All
>>>>>> the time we talk about making things easy
>> so
>>>> people will
>>>>>> contribute, Why do you want to resist a
>> seasoned
>>>> contributer
>>>>>> for working. I'll rather have expect
>> community
>>>> will
>>>>>> support. All the time he has been asking
>> people to
>>>> tell him
>>>>>> suggestions, wish list etc. Why not
>> support him
>>>> and get more
>>>>>> out of him instead.
>>>>>
>>>>> If we can't invite the community to
>> participate -
>>>> as I suggested - then that only proves what I
>> suspect - that
>>>> this is a design that is being foisted on the
>> community.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
What is your list of requirements Adrian??
On May 1, 2009, at 11:12 PM, Adrian Crum wrote:
>
> That's exactly what I'm suggesting. In the end we will have a much
> better implementation - one that will address everyone's issues and
> incorporate everyone's solutions.
>
> It will be more productive because we will work out problems on the
> drawing board, not in deployment bugs.
>
> -Adrian
>
>
> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>
>> From: Scott Gray <sc...@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
>> scratch?
>> I don't see how that would be more productive than
>> working from a
>> proposal which is exactly what the design can be treated
>> as.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 2:56 PM, Adrian Crum wrote:
>>
>>>
>>> It's not the same! There is a big difference
>> between "Here's my
>>> design, what do you think?" and "I'm
>> interested in refactoring the
>>> security framework. Could you help me with the
>> design?"
>>>
>>> -Adrian
>>>
>>> --- On Fri, 5/1/09, Scott Gray
>> <sc...@hotwaxmedia.com> wrote:
>>>
>>>> From: Scott Gray
>> <sc...@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 at least we have a starting
>> point.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> How about we start over and collaborate on a
>> design?
>>>> Is that so much
>>>>> different?
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> --- On Fri, 5/1/09, Scott Gray
>>>> <sc...@hotwaxmedia.com> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>> <sc...@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
>>>>>> 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.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 2/05/2009, at 2:19 PM, Adrian Crum
>> wrote:
>>>>>>
>>>>>>>
>>>>>>> --- On Fri, 5/1/09, Anil Patel
>>>>>> <an...@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 only started after
>> Adrian and
>>>> Jacques
>>>>>> showed
>>>>>>>> interest by commenting on the
>> page.
>>>>>>>
>>>>>>> The only interest I showed was that I
>> agreed
>>>> that
>>>>>> OFBiz security could use improvement, and
>> I
>>>> suggested he use
>>>>>> a third party library. I did not endorse
>> or
>>>> approve of his
>>>>>> design.
>>>>>>>
>>>>>>>> Andrew has been actively
>> explaining his
>>>> idea all
>>>>>> this time.
>>>>>>>
>>>>>>> As I demonstrated in another reply, no
>> he did
>>>> not.
>>>>>> Only a few days went by between
>> introducing the
>>>> idea and
>>>>>> committing code.
>>>>>>>
>>>>>>>> The work done till date is not
>> blocking
>>>> anybody,
>>>>>> old
>>>>>>>> security system is still in place.
>> New
>>>> system is
>>>>>> implemented
>>>>>>>> in example component so its lot
>> easy for
>>>> him to
>>>>>> explain and
>>>>>>>> people to understand.
>>>>>>>
>>>>>>> What if the new work is a bad design?
>> How will
>>>> we know
>>>>>> that until everyone has had time to
>> evaluate it?
>>>>>>>
>>>>>>>> People have different ways of
>> working in
>>>>>> community, Joe is
>>>>>>>> committer still all the time he
>> creates
>>>> Jira issue
>>>>>> and
>>>>>>>> uploads his patch and most of time
>> its
>>>> somebody
>>>>>> else who
>>>>>>>> does commits, but that's his
>> way of
>>>> working.
>>>>>> If we
>>>>>>>> don't do what Joe does then
>> why should
>>>> Andrew
>>>>>> do what
>>>>>>>> Adrian does.
>>>>>>>
>>>>>>> As far as I know, Joe submits patches
>> for
>>>> things he
>>>>>> doesn't have commit rights to.
>>>>>>>
>>>>>>>> I don't see any reason why we
>> should
>>>> start
>>>>>> over.
>>>>>>>
>>>>>>> Do you see a reason why we
>> shouldn't? Will
>>>> the
>>>>>> project suffer immensely if we pause and
>> wait for
>>>> others to
>>>>>> comment? Is there some catastrophe looming
>> that
>>>> requires us
>>>>>> to rush this through?
>>>>>>>
>>>>>>>> All
>>>>>>>> the time we talk about making
>> things easy
>>>> so
>>>>>> people will
>>>>>>>> contribute, Why do you want to
>> resist a
>>>> seasoned
>>>>>> contributer
>>>>>>>> for working. I'll rather have
>> expect
>>>> community
>>>>>> will
>>>>>>>> support. All the time he has been
>> asking
>>>> people to
>>>>>> tell him
>>>>>>>> suggestions, wish list etc. Why
>> not
>>>> support him
>>>>>> and get more
>>>>>>>> out of him instead.
>>>>>>>
>>>>>>> If we can't invite the community
>> to
>>>> participate -
>>>>>> as I suggested - then that only proves
>> what I
>>>> suspect - that
>>>>>> this is a design that is being foisted on
>> the
>>>> community.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
That's exactly what I'm suggesting. In the end we will have a much better implementation - one that will address everyone's issues and incorporate everyone's solutions.
It will be more productive because we will work out problems on the drawing board, not in deployment bugs.
-Adrian
--- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@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
> scratch?
> I don't see how that would be more productive than
> working from a
> proposal which is exactly what the design can be treated
> as.
>
> Regards
> Scott
>
> On 2/05/2009, at 2:56 PM, Adrian Crum wrote:
>
> >
> > It's not the same! There is a big difference
> between "Here's my
> > design, what do you think?" and "I'm
> interested in refactoring the
> > security framework. Could you help me with the
> design?"
> >
> > -Adrian
> >
> > --- On Fri, 5/1/09, Scott Gray
> <sc...@hotwaxmedia.com> wrote:
> >
> >> From: Scott Gray
> <sc...@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 at least we have a starting
> point.
> >>
> >> Regards
> >> Scott
> >>
> >> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
> >>
> >>>
> >>> How about we start over and collaborate on a
> design?
> >> Is that so much
> >>> different?
> >>>
> >>> -Adrian
> >>>
> >>>
> >>> --- On Fri, 5/1/09, Scott Gray
> >> <sc...@hotwaxmedia.com> wrote:
> >>>
> >>>> From: Scott Gray
> >> <sc...@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
> >>>> 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.
> >>>>
> >>>> Regards
> >>>> Scott
> >>>>
> >>>> On 2/05/2009, at 2:19 PM, Adrian Crum
> wrote:
> >>>>
> >>>>>
> >>>>> --- On Fri, 5/1/09, Anil Patel
> >>>> <an...@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 only started after
> Adrian and
> >> Jacques
> >>>> showed
> >>>>>> interest by commenting on the
> page.
> >>>>>
> >>>>> The only interest I showed was that I
> agreed
> >> that
> >>>> OFBiz security could use improvement, and
> I
> >> suggested he use
> >>>> a third party library. I did not endorse
> or
> >> approve of his
> >>>> design.
> >>>>>
> >>>>>> Andrew has been actively
> explaining his
> >> idea all
> >>>> this time.
> >>>>>
> >>>>> As I demonstrated in another reply, no
> he did
> >> not.
> >>>> Only a few days went by between
> introducing the
> >> idea and
> >>>> committing code.
> >>>>>
> >>>>>> The work done till date is not
> blocking
> >> anybody,
> >>>> old
> >>>>>> security system is still in place.
> New
> >> system is
> >>>> implemented
> >>>>>> in example component so its lot
> easy for
> >> him to
> >>>> explain and
> >>>>>> people to understand.
> >>>>>
> >>>>> What if the new work is a bad design?
> How will
> >> we know
> >>>> that until everyone has had time to
> evaluate it?
> >>>>>
> >>>>>> People have different ways of
> working in
> >>>> community, Joe is
> >>>>>> committer still all the time he
> creates
> >> Jira issue
> >>>> and
> >>>>>> uploads his patch and most of time
> its
> >> somebody
> >>>> else who
> >>>>>> does commits, but that's his
> way of
> >> working.
> >>>> If we
> >>>>>> don't do what Joe does then
> why should
> >> Andrew
> >>>> do what
> >>>>>> Adrian does.
> >>>>>
> >>>>> As far as I know, Joe submits patches
> for
> >> things he
> >>>> doesn't have commit rights to.
> >>>>>
> >>>>>> I don't see any reason why we
> should
> >> start
> >>>> over.
> >>>>>
> >>>>> Do you see a reason why we
> shouldn't? Will
> >> the
> >>>> project suffer immensely if we pause and
> wait for
> >> others to
> >>>> comment? Is there some catastrophe looming
> that
> >> requires us
> >>>> to rush this through?
> >>>>>
> >>>>>> All
> >>>>>> the time we talk about making
> things easy
> >> so
> >>>> people will
> >>>>>> contribute, Why do you want to
> resist a
> >> seasoned
> >>>> contributer
> >>>>>> for working. I'll rather have
> expect
> >> community
> >>>> will
> >>>>>> support. All the time he has been
> asking
> >> people to
> >>>> tell him
> >>>>>> suggestions, wish list etc. Why
> not
> >> support him
> >>>> and get more
> >>>>>> out of him instead.
> >>>>>
> >>>>> If we can't invite the community
> to
> >> participate -
> >>>> as I suggested - then that only proves
> what I
> >> suspect - that
> >>>> this is a design that is being foisted on
> the
> >> community.
> >>>>>
> >>>>> -Adrian
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
So what are you suggesting, scrap the design and start from scratch?
I don't see how that would be more productive than working from a
proposal which is exactly what the design can be treated as.
Regards
Scott
On 2/05/2009, at 2:56 PM, Adrian Crum wrote:
>
> It's not the same! There is a big difference between "Here's my
> design, what do you think?" and "I'm interested in refactoring the
> security framework. Could you help me with the design?"
>
> -Adrian
>
> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>
>> From: Scott Gray <sc...@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 at least we have a starting point.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>>
>>>
>>> How about we start over and collaborate on a design?
>> Is that so much
>>> different?
>>>
>>> -Adrian
>>>
>>>
>>> --- On Fri, 5/1/09, Scott Gray
>> <sc...@hotwaxmedia.com> wrote:
>>>
>>>> From: Scott Gray
>> <sc...@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
>>>> 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.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> --- On Fri, 5/1/09, Anil Patel
>>>> <an...@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 only started after Adrian and
>> Jacques
>>>> showed
>>>>>> interest by commenting on the page.
>>>>>
>>>>> The only interest I showed was that I agreed
>> that
>>>> OFBiz security could use improvement, and I
>> suggested he use
>>>> a third party library. I did not endorse or
>> approve of his
>>>> design.
>>>>>
>>>>>> Andrew has been actively explaining his
>> idea all
>>>> this time.
>>>>>
>>>>> As I demonstrated in another reply, no he did
>> not.
>>>> Only a few days went by between introducing the
>> idea and
>>>> committing code.
>>>>>
>>>>>> The work done till date is not blocking
>> anybody,
>>>> old
>>>>>> security system is still in place. New
>> system is
>>>> implemented
>>>>>> in example component so its lot easy for
>> him to
>>>> explain and
>>>>>> people to understand.
>>>>>
>>>>> What if the new work is a bad design? How will
>> we know
>>>> that until everyone has had time to evaluate it?
>>>>>
>>>>>> People have different ways of working in
>>>> community, Joe is
>>>>>> committer still all the time he creates
>> Jira issue
>>>> and
>>>>>> uploads his patch and most of time its
>> somebody
>>>> else who
>>>>>> does commits, but that's his way of
>> working.
>>>> If we
>>>>>> don't do what Joe does then why should
>> Andrew
>>>> do what
>>>>>> Adrian does.
>>>>>
>>>>> As far as I know, Joe submits patches for
>> things he
>>>> doesn't have commit rights to.
>>>>>
>>>>>> I don't see any reason why we should
>> start
>>>> over.
>>>>>
>>>>> Do you see a reason why we shouldn't? Will
>> the
>>>> project suffer immensely if we pause and wait for
>> others to
>>>> comment? Is there some catastrophe looming that
>> requires us
>>>> to rush this through?
>>>>>
>>>>>> All
>>>>>> the time we talk about making things easy
>> so
>>>> people will
>>>>>> contribute, Why do you want to resist a
>> seasoned
>>>> contributer
>>>>>> for working. I'll rather have expect
>> community
>>>> will
>>>>>> support. All the time he has been asking
>> people to
>>>> tell him
>>>>>> suggestions, wish list etc. Why not
>> support him
>>>> and get more
>>>>>> out of him instead.
>>>>>
>>>>> If we can't invite the community to
>> participate -
>>>> as I suggested - then that only proves what I
>> suspect - that
>>>> this is a design that is being foisted on the
>> community.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
It's not the same! There is a big difference between "Here's my design, what do you think?" and "I'm interested in refactoring the security framework. Could you help me with the design?"
-Adrian
--- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@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 at least we have a starting point.
>
> Regards
> Scott
>
> On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>
> >
> > How about we start over and collaborate on a design?
> Is that so much
> > different?
> >
> > -Adrian
> >
> >
> > --- On Fri, 5/1/09, Scott Gray
> <sc...@hotwaxmedia.com> wrote:
> >
> >> From: Scott Gray
> <sc...@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
> >> 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.
> >>
> >> Regards
> >> Scott
> >>
> >> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
> >>
> >>>
> >>> --- On Fri, 5/1/09, Anil Patel
> >> <an...@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 only started after Adrian and
> Jacques
> >> showed
> >>>> interest by commenting on the page.
> >>>
> >>> The only interest I showed was that I agreed
> that
> >> OFBiz security could use improvement, and I
> suggested he use
> >> a third party library. I did not endorse or
> approve of his
> >> design.
> >>>
> >>>> Andrew has been actively explaining his
> idea all
> >> this time.
> >>>
> >>> As I demonstrated in another reply, no he did
> not.
> >> Only a few days went by between introducing the
> idea and
> >> committing code.
> >>>
> >>>> The work done till date is not blocking
> anybody,
> >> old
> >>>> security system is still in place. New
> system is
> >> implemented
> >>>> in example component so its lot easy for
> him to
> >> explain and
> >>>> people to understand.
> >>>
> >>> What if the new work is a bad design? How will
> we know
> >> that until everyone has had time to evaluate it?
> >>>
> >>>> People have different ways of working in
> >> community, Joe is
> >>>> committer still all the time he creates
> Jira issue
> >> and
> >>>> uploads his patch and most of time its
> somebody
> >> else who
> >>>> does commits, but that's his way of
> working.
> >> If we
> >>>> don't do what Joe does then why should
> Andrew
> >> do what
> >>>> Adrian does.
> >>>
> >>> As far as I know, Joe submits patches for
> things he
> >> doesn't have commit rights to.
> >>>
> >>>> I don't see any reason why we should
> start
> >> over.
> >>>
> >>> Do you see a reason why we shouldn't? Will
> the
> >> project suffer immensely if we pause and wait for
> others to
> >> comment? Is there some catastrophe looming that
> requires us
> >> to rush this through?
> >>>
> >>>> All
> >>>> the time we talk about making things easy
> so
> >> people will
> >>>> contribute, Why do you want to resist a
> seasoned
> >> contributer
> >>>> for working. I'll rather have expect
> community
> >> will
> >>>> support. All the time he has been asking
> people to
> >> tell him
> >>>> suggestions, wish list etc. Why not
> support him
> >> and get more
> >>>> out of him instead.
> >>>
> >>> If we can't invite the community to
> participate -
> >> as I suggested - then that only proves what I
> suspect - that
> >> this is a design that is being foisted on the
> community.
> >>>
> >>> -Adrian
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
Scott
On 2/05/2009, at 2:37 PM, Adrian Crum wrote:
>
> How about we start over and collaborate on a design? Is that so much
> different?
>
> -Adrian
>
>
> --- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
>
>> From: Scott Gray <sc...@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
>> 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.
>>
>> Regards
>> Scott
>>
>> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>>
>>>
>>> --- On Fri, 5/1/09, Anil Patel
>> <an...@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 only started after Adrian and Jacques
>> showed
>>>> interest by commenting on the page.
>>>
>>> The only interest I showed was that I agreed that
>> OFBiz security could use improvement, and I suggested he use
>> a third party library. I did not endorse or approve of his
>> design.
>>>
>>>> Andrew has been actively explaining his idea all
>> this time.
>>>
>>> As I demonstrated in another reply, no he did not.
>> Only a few days went by between introducing the idea and
>> committing code.
>>>
>>>> The work done till date is not blocking anybody,
>> old
>>>> security system is still in place. New system is
>> implemented
>>>> in example component so its lot easy for him to
>> explain and
>>>> people to understand.
>>>
>>> What if the new work is a bad design? How will we know
>> that until everyone has had time to evaluate it?
>>>
>>>> People have different ways of working in
>> community, Joe is
>>>> committer still all the time he creates Jira issue
>> and
>>>> uploads his patch and most of time its somebody
>> else who
>>>> does commits, but that's his way of working.
>> If we
>>>> don't do what Joe does then why should Andrew
>> do what
>>>> Adrian does.
>>>
>>> As far as I know, Joe submits patches for things he
>> doesn't have commit rights to.
>>>
>>>> I don't see any reason why we should start
>> over.
>>>
>>> Do you see a reason why we shouldn't? Will the
>> project suffer immensely if we pause and wait for others to
>> comment? Is there some catastrophe looming that requires us
>> to rush this through?
>>>
>>>> All
>>>> the time we talk about making things easy so
>> people will
>>>> contribute, Why do you want to resist a seasoned
>> contributer
>>>> for working. I'll rather have expect community
>> will
>>>> support. All the time he has been asking people to
>> tell him
>>>> suggestions, wish list etc. Why not support him
>> and get more
>>>> out of him instead.
>>>
>>> If we can't invite the community to participate -
>> as I suggested - then that only proves what I suspect - that
>> this is a design that is being foisted on the community.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
How about we start over and collaborate on a design? Is that so much different?
-Adrian
--- On Fri, 5/1/09, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@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
> 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.
>
> Regards
> Scott
>
> On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>
> >
> > --- On Fri, 5/1/09, Anil Patel
> <an...@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 only started after Adrian and Jacques
> showed
> >> interest by commenting on the page.
> >
> > The only interest I showed was that I agreed that
> OFBiz security could use improvement, and I suggested he use
> a third party library. I did not endorse or approve of his
> design.
> >
> >> Andrew has been actively explaining his idea all
> this time.
> >
> > As I demonstrated in another reply, no he did not.
> Only a few days went by between introducing the idea and
> committing code.
> >
> >> The work done till date is not blocking anybody,
> old
> >> security system is still in place. New system is
> implemented
> >> in example component so its lot easy for him to
> explain and
> >> people to understand.
> >
> > What if the new work is a bad design? How will we know
> that until everyone has had time to evaluate it?
> >
> >> People have different ways of working in
> community, Joe is
> >> committer still all the time he creates Jira issue
> and
> >> uploads his patch and most of time its somebody
> else who
> >> does commits, but that's his way of working.
> If we
> >> don't do what Joe does then why should Andrew
> do what
> >> Adrian does.
> >
> > As far as I know, Joe submits patches for things he
> doesn't have commit rights to.
> >
> >> I don't see any reason why we should start
> over.
> >
> > Do you see a reason why we shouldn't? Will the
> project suffer immensely if we pause and wait for others to
> comment? Is there some catastrophe looming that requires us
> to rush this through?
> >
> >> All
> >> the time we talk about making things easy so
> people will
> >> contribute, Why do you want to resist a seasoned
> contributer
> >> for working. I'll rather have expect community
> will
> >> support. All the time he has been asking people to
> tell him
> >> suggestions, wish list etc. Why not support him
> and get more
> >> out of him instead.
> >
> > If we can't invite the community to participate -
> as I suggested - then that only proves what I suspect - that
> this is a design that is being foisted on the community.
> >
> > -Adrian
> >
> >
> >
> >
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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.
Regards
Scott
On 2/05/2009, at 2:19 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Anil Patel <an...@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 only started after Adrian and Jacques showed
>> interest by commenting on the page.
>
> The only interest I showed was that I agreed that OFBiz security
> could use improvement, and I suggested he use a third party library.
> I did not endorse or approve of his design.
>
>> Andrew has been actively explaining his idea all this time.
>
> As I demonstrated in another reply, no he did not. Only a few days
> went by between introducing the idea and committing code.
>
>> The work done till date is not blocking anybody, old
>> security system is still in place. New system is implemented
>> in example component so its lot easy for him to explain and
>> people to understand.
>
> What if the new work is a bad design? How will we know that until
> everyone has had time to evaluate it?
>
>> People have different ways of working in community, Joe is
>> committer still all the time he creates Jira issue and
>> uploads his patch and most of time its somebody else who
>> does commits, but that's his way of working. If we
>> don't do what Joe does then why should Andrew do what
>> Adrian does.
>
> As far as I know, Joe submits patches for things he doesn't have
> commit rights to.
>
>> I don't see any reason why we should start over.
>
> Do you see a reason why we shouldn't? Will the project suffer
> immensely if we pause and wait for others to comment? Is there some
> catastrophe looming that requires us to rush this through?
>
>> All
>> the time we talk about making things easy so people will
>> contribute, Why do you want to resist a seasoned contributer
>> for working. I'll rather have expect community will
>> support. All the time he has been asking people to tell him
>> suggestions, wish list etc. Why not support him and get more
>> out of him instead.
>
> If we can't invite the community to participate - as I suggested -
> then that only proves what I suspect - that this is a design that is
> being foisted on the community.
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Anil Patel <an...@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 only started after Adrian and Jacques showed
> interest by commenting on the page.
The only interest I showed was that I agreed that OFBiz security could use improvement, and I suggested he use a third party library. I did not endorse or approve of his design.
> Andrew has been actively explaining his idea all this time.
As I demonstrated in another reply, no he did not. Only a few days went by between introducing the idea and committing code.
> The work done till date is not blocking anybody, old
> security system is still in place. New system is implemented
> in example component so its lot easy for him to explain and
> people to understand.
What if the new work is a bad design? How will we know that until everyone has had time to evaluate it?
> People have different ways of working in community, Joe is
> committer still all the time he creates Jira issue and
> uploads his patch and most of time its somebody else who
> does commits, but that's his way of working. If we
> don't do what Joe does then why should Andrew do what
> Adrian does.
As far as I know, Joe submits patches for things he doesn't have commit rights to.
> I don't see any reason why we should start over.
Do you see a reason why we shouldn't? Will the project suffer immensely if we pause and wait for others to comment? Is there some catastrophe looming that requires us to rush this through?
> All
> the time we talk about making things easy so people will
> contribute, Why do you want to resist a seasoned contributer
> for working. I'll rather have expect community will
> support. All the time he has been asking people to tell him
> suggestions, wish list etc. Why not support him and get more
> out of him instead.
If we can't invite the community to participate - as I suggested - then that only proves what I suspect - that this is a design that is being foisted on the community.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 explaining his idea all this time. The work
done till date is not blocking anybody, old security system is still
in place. New system is implemented in example component so its lot
easy for him to explain and people to understand.
People have different ways of working in community, Joe is committer
still all the time he creates Jira issue and uploads his patch and
most of time its somebody else who does commits, but that's his way of
working. If we don't do what Joe does then why should Andrew do what
Adrian does.
I don't see any reason why we should start over. All the time we talk
about making things easy so people will contribute, Why do you want to
resist a seasoned contributer for working. I'll rather have expect
community will support. All the time he has been asking people to tell
him suggestions, wish list etc. Why not support him and get more out
of him instead.
Regards
Anil Patel
On May 1, 2009, at 10:03 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Andrew Zeneski <an...@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 in OFBiz.
>
> Things ARE being said. Let's start over and do this as a community.
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Andrew Zeneski <an...@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 in OFBiz.
Things ARE being said. Let's start over and do this as a community.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 of migrating the applications, but that is going to
change soon...
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
at all, the discussion is solely around whether or not code should
have been implemented or not. Let's face it, these documents have been
in front of you for over a week, and there was not a single objection
or concern raised until today. I have only a limited amount of free
time, and if I am going to following this effort through to the end,
it needs to have a steady progression. So to be frank, get over it.
Code is being worked on actively for this effort, and I am expecting
more involvement as soon as the API is finalized. 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 in OFBiz.
Andrew
On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>> over time? of course it will but I think it's a much
>> better base to work from.
>
> I don't know if you were around at the time, but I was. One of the
> "weaknesses" Andrew is trying to fix with this latest effort is the
> permissions services - another design he introduced a couple years
> ago. Everyone went along with it and re-wrote code to use service
> permissions. (I spent several weekends just converting the
> accounting component over to the new security implementation). Now
> we're being told "Oops, that design is limited, let me try again."
>
> Why would anyone have any objection to opening this up to the
> community before we start writing code? Maybe there are others who
> see weaknesses in the new design. Give them a chance to offer input.
>
> -Adrian
>
>
>
>
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 2/05/2009, at 1:55 PM, Adrian Crum wrote:
>
>> 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 redesigned? "Those who ignore history are
> doomed to repeat it."
I think there is a big difference between making an improvement to an
existing framework and completely redesigning a framework. Your
original comment implied that Andrew's previous work was flawed and I
was trying to point out that there was nothing wrong with the last
refactor, it was a perfectly valid improvement to what was in place
before it.
> What is the problem here? Are you that convinced that Andrew's
> implementation is perfect? That there's no room for improvement or
> other opinions?
In case your memory is shortening here's what I wrote previously in
this thread:
>> Will it need improvement over time? of course it will but I think
>> it's a much better base to work from.
Let me be clear, I have no problem here whatsoever, I'm just
countering arguments that the community wasn't given an opportunity to
be involved because it was and still does.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
> 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 redesigned? "Those who ignore history are doomed to repeat it."
What is the problem here? Are you that convinced that Andrew's implementation is perfect? That there's no room for improvement or other opinions?
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 2/05/2009, at 12:38 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>> over time? of course it will but I think it's a much
>> better base to work from.
>
> I don't know if you were around at the time, but I was. One of the
> "weaknesses" Andrew is trying to fix with this latest effort is the
> permissions services - another design he introduced a couple years
> ago. Everyone went along with it and re-wrote code to use service
> permissions. (I spent several weekends just converting the
> accounting component over to the new security implementation). Now
> we're being told "Oops, that design is limited, let me try again."
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.
> Why would anyone have any objection to opening this up to the
> community before we start writing code? Maybe there are others who
> see weaknesses in the new design. Give them a chance to offer input.
The point is that it was opened up to the community before any code
was written, all that needed to happen to delay coding was for someone
to say that they needed time. Collaboration is a two way street and
it shouldn't be up to the proposer to check to see if you're
considering making a comment at some point you should just say so.
Regards
Scott
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by BJ Freeman <bj...@free-man.net>.
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 you have been very involved with this so it seems a no brainier.
I on the other hand have to first get my head around your concept.
then compare against the old way. That takes me at least a week or more
with everything else that is going on in my life.
I do believe in code review, seeing the weaknesses an strengths of both
systems. However that take a lot to cover this big a system.
So in my view, have a target of three months before implementing with
review as active as it is now would be what I consider normal.
My reason of not speaking up till now, I am still working this through
in my mind.\
I actually had some question that I wanted clarified. Till I saw the
discussion had turned in a none review vane.
I will post those under a separate email.
as a humorous side note you massive patch and the the revert got
rejected by my mail server which is set to reject in file 40K or more.
Andrew Zeneski sent the following on 5/1/2009 6:30 PM:
> 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 of migrating the applications, but that is going to change soon...
>
> 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 at all, the
> discussion is solely around whether or not code should have been
> implemented or not. Let's face it, these documents have been in front of
> you for over a week, and there was not a single objection or concern
> raised until today. I have only a limited amount of free time, and if I
> am going to following this effort through to the end, it needs to have a
> steady progression. So to be frank, get over it.
>
> Code is being worked on actively for this effort, and I am expecting
> more involvement as soon as the API is finalized. 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 in OFBiz.
>
> Andrew
>
>
>
> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>
>>
>> --- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
>>> over time? of course it will but I think it's a much
>>> better base to work from.
>>
>> I don't know if you were around at the time, but I was. One of the
>> "weaknesses" Andrew is trying to fix with this latest effort is the
>> permissions services - another design he introduced a couple years
>> ago. Everyone went along with it and re-wrote code to use service
>> permissions. (I spent several weekends just converting the accounting
>> component over to the new security implementation). Now we're being
>> told "Oops, that design is limited, let me try again."
>>
>> Why would anyone have any objection to opening this up to the
>> community before we start writing code? Maybe there are others who see
>> weaknesses in the new design. Give them a chance to offer input.
>>
>> -Adrian
>>
>>
>>
>>
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Scott Gray <sc...@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 AND simplicity. Will it need improvement
> over time? of course it will but I think it's a much
> better base to work from.
I don't know if you were around at the time, but I was. One of the "weaknesses" Andrew is trying to fix with this latest effort is the permissions services - another design he introduced a couple years ago. Everyone went along with it and re-wrote code to use service permissions. (I spent several weekends just converting the accounting component over to the new security implementation). Now we're being told "Oops, that design is limited, let me try again."
Why would anyone have any objection to opening this up to the community before we start writing code? Maybe there are others who see weaknesses in the new design. Give them a chance to offer input.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 will but I think it's a much better base to work from.
Inline
On 2/05/2009, at 9:45 AM, Adrian Crum wrote:
>
>
> --- On Fri, 5/1/09, Andrew Zeneski <an...@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. That is the
>> single point of contact, the hasPermission() method.
>>
>> The checks in the screen definition runs the same code as
>> the checks in service definition. So now one advantage is,
>> the update or delete button which is displayed in the UI if
>> the user has permission will display (even if they do not
>> have the static permission associated with their account) if
>> the user can edit that specific item. It won't display
>> for other items which the user cannot modify.
>
> I must be missing something. Still using the Example component as an
> example: the service definition called a service permission, which
> called a script, which ultimately called Security.hasPermission.
> Your modification has the service definition use the <required-
> permissions> which ultimately calls authz.hasPermission(). So, both
> methods end up calling a single hasPermission() method. What changed?
>
> The only difference I see is that the permission string moved from a
> script to the service definition. Is that the desired benefit?
I think it's an improvement, you can directly see what permissions are
required on the service without having to find a service def and then
it's method. The newer permissions are more intelligent so you don't
need to write a service for every variation in auth requirements.
>
>
>>>> 3. Avoid having to check multiple permissions, for
>> example
>>>> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use
>> a new
>>>> permission format which embeds all permissions
>> which will be
>>>> accepted:
>>>
>>> I don't see that being done explicitly in our
>> current code. The OFBizSecurity class does that
>> automatically. Any permission check is done with the ADMIN
>> permission first, then the requested permission.
>>
>> Okay, so that was a bad example. How about CATALOG_UPDATE
>> or CATALOG_ROLE_UPDATE instead as an example. Instead a
>> simple permission defined as update:catalog:${catalogId}
>> would take care of both of these. If the user has the static
>> 'update:catalog' permission it would be granted
>> (like a catalog admin might have), otherwise it would run
>> the DA logic to determine if the user has permission to
>> update that specific catalog.
>
> The idea of specifying some kind of parameter in the permission is
> interesting. The question is, (speaking as a user) What does that
> parameter do?
It runs dynamic access script defined on the SecurityPermission record
>
>>>> 4. Define permission for users, not admins.
>> Instead of
>>>> looking for a static permission, set the
>> permission to be
>>>> checked at the most granular level. When doing so,
>> admin
>>>> users will always have permission and the API will
>> handle
>>>> user access using DA logic.
>>>
>>> I disagree. I might want my application to behave
>> differently if an admin is using it. Without an admin
>> permission (or attribute), how will I know if a user is in
>> an admin role?
>>
>> Then we will create an 'admin' base permission. I
>> didn't see the need for it, b/c I can't think of
>> anything in which I would say "don't show this to
>> people who can access/create/read/update/delete; only show
>> it to an admin". I have nothing against this, just
>> couldn't think of any really useful cases. Do you have
>> something specific in mind?
>
> Maybe that could be expressed as :component:admin.
I would rather hear an example of what this would be used for before
figuring out how to add it.
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Andrew Zeneski <an...@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. That is the
> single point of contact, the hasPermission() method.
>
> The checks in the screen definition runs the same code as
> the checks in service definition. So now one advantage is,
> the update or delete button which is displayed in the UI if
> the user has permission will display (even if they do not
> have the static permission associated with their account) if
> the user can edit that specific item. It won't display
> for other items which the user cannot modify.
I must be missing something. Still using the Example component as an example: the service definition called a service permission, which called a script, which ultimately called Security.hasPermission. Your modification has the service definition use the <required-permissions> which ultimately calls authz.hasPermission(). So, both methods end up calling a single hasPermission() method. What changed?
The only difference I see is that the permission string moved from a script to the service definition. Is that the desired benefit?
> >> 3. Avoid having to check multiple permissions, for
> example
> >> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use
> a new
> >> permission format which embeds all permissions
> which will be
> >> accepted:
> >
> > I don't see that being done explicitly in our
> current code. The OFBizSecurity class does that
> automatically. Any permission check is done with the ADMIN
> permission first, then the requested permission.
>
> Okay, so that was a bad example. How about CATALOG_UPDATE
> or CATALOG_ROLE_UPDATE instead as an example. Instead a
> simple permission defined as update:catalog:${catalogId}
> would take care of both of these. If the user has the static
> 'update:catalog' permission it would be granted
> (like a catalog admin might have), otherwise it would run
> the DA logic to determine if the user has permission to
> update that specific catalog.
The idea of specifying some kind of parameter in the permission is interesting. The question is, (speaking as a user) What does that parameter do?
> >> 4. Define permission for users, not admins.
> Instead of
> >> looking for a static permission, set the
> permission to be
> >> checked at the most granular level. When doing so,
> admin
> >> users will always have permission and the API will
> handle
> >> user access using DA logic.
> >
> > I disagree. I might want my application to behave
> differently if an admin is using it. Without an admin
> permission (or attribute), how will I know if a user is in
> an admin role?
>
> Then we will create an 'admin' base permission. I
> didn't see the need for it, b/c I can't think of
> anything in which I would say "don't show this to
> people who can access/create/read/update/delete; only show
> it to an admin". I have nothing against this, just
> couldn't think of any really useful cases. Do you have
> something specific in mind?
Maybe that could be expressed as :component:admin.
-Adrian
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
On May 1, 2009, at 4:23 PM, Adrian Crum wrote:
>
> --- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com>
> wrote:
>> From: Andrew Zeneski <an...@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 checks, instead
>> of having security embedded in functionality, or tied to
>> services directly, the API should be the governor of all
>> security. This means no more writing security logic in the
>> functionality, and no more permission services attached
>> directly to functionality (services or ecas). This is a bad
>> design IMHO because it spreads the permission logic around
>> in multiple places and makes it impossible to get the same
>> results when checking permissions from different framework
>> tools.
>
> I don't understand what this means. Looking at the changes you made
> in the Example component, you still have permissions tied to the
> service definitions. Then you have permissions being checked in the
> screen widgets. From my perspective, nothing changed except the
> format of the permission string. Where is the "single point of
> contact" in the Example component?
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. That is the single point of contact, the hasPermission()
method.
The checks in the screen definition runs the same code as the checks
in service definition. So now one advantage is, the update or delete
button which is displayed in the UI if the user has permission will
display (even if they do not have the static permission associated
with their account) if the user can edit that specific item. It won't
display for other items which the user cannot modify.
>
>> 3. Avoid having to check multiple permissions, for example
>> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new
>> permission format which embeds all permissions which will be
>> accepted:
>
> I don't see that being done explicitly in our current code. The
> OFBizSecurity class does that automatically. Any permission check is
> done with the ADMIN permission first, then the requested permission.
Okay, so that was a bad example. How about CATALOG_UPDATE or
CATALOG_ROLE_UPDATE instead as an example. Instead a simple permission
defined as update:catalog:${catalogId} would take care of both of
these. If the user has the static 'update:catalog' permission it would
be granted (like a catalog admin might have), otherwise it would run
the DA logic to determine if the user has permission to update that
specific catalog.
One single permission, can handle most if not all cases when defined
properly.
>
>> 4. Define permission for users, not admins. Instead of
>> looking for a static permission, set the permission to be
>> checked at the most granular level. When doing so, admin
>> users will always have permission and the API will handle
>> user access using DA logic.
>
> I disagree. I might want my application to behave differently if an
> admin is using it. Without an admin permission (or attribute), how
> will I know if a user is in an admin role?
Then we will create an 'admin' base permission. I didn't see the need
for it, b/c I can't think of anything in which I would say "don't show
this to people who can access/create/read/update/delete; only show it
to an admin". I have nothing against this, just couldn't think of any
really useful cases. Do you have something specific in mind?
Andrew
Re: Authz API Discussion (was re: svn commit: r770084)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Fri, 5/1/09, Andrew Zeneski <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@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 checks, instead
> of having security embedded in functionality, or tied to
> services directly, the API should be the governor of all
> security. This means no more writing security logic in the
> functionality, and no more permission services attached
> directly to functionality (services or ecas). This is a bad
> design IMHO because it spreads the permission logic around
> in multiple places and makes it impossible to get the same
> results when checking permissions from different framework
> tools.
I don't understand what this means. Looking at the changes you made in the Example component, you still have permissions tied to the service definitions. Then you have permissions being checked in the screen widgets. From my perspective, nothing changed except the format of the permission string. Where is the "single point of contact" in the Example component?
> 3. Avoid having to check multiple permissions, for example
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new
> permission format which embeds all permissions which will be
> accepted:
I don't see that being done explicitly in our current code. The OFBizSecurity class does that automatically. Any permission check is done with the ADMIN permission first, then the requested permission.
> 4. Define permission for users, not admins. Instead of
> looking for a static permission, set the permission to be
> checked at the most granular level. When doing so, admin
> users will always have permission and the API will handle
> user access using DA logic.
I disagree. I might want my application to behave differently if an admin is using it. Without an admin permission (or attribute), how will I know if a user is in an admin role?
-Adrian
Authz API Discussion (was re: svn commit: r770084)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 functionality, or tied to services directly, the
API should be the governor of all security. This means no more writing
security logic in the functionality, and no more permission services
attached directly to functionality (services or ecas). This is a bad
design IMHO because it spreads the permission logic around in multiple
places and makes it impossible to get the same results when checking
permissions from different framework tools.
-- We want to be consistent, and be able to obtain the same
information from the UI or screen/form as we would get from a service
call.
-- Main point of contact is the Authorization interface.
2. Permission services become Dynamic Access (DA). Now instead of
having permission services attached to services, we have Dynamic
Access implementations which can be a compiled Java object, a Groovy
script or a Service. My personal preference here is the Groovy script,
but the API current supports all three. This DA logic is attached to a
permission instead of a service.
-- This allows for extending or changing the permission logic for a
specific implementation/customization/application much easier. Since
the DAs are all data driven, changing the seed data you can change the
logic which is used. This means you no longer have to customize the
services or logic in OFBiz to change the way authorization is handled
for your company (or client); one less thing to worry about when
merging customizations with the open source project.
-- for groovy use "component://path/to/script.groovy" in the
dynamicAccess field on SecurityPermission.
-- for services use "service:serviceName" in the dynamicAccess field
on SecurityPermission
-- for objects use "org.ofbiz.path.to.Object (which implements
DynamicAccess)" in the dynamicAccess field on SecurityPermission
3. Avoid having to check multiple permissions, for example
PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission
format which embeds all permissions which will be accepted:
Example: update:party:contact:10000 - Update the contact information
for party 10000
This will allow anyone who has:
"update" or "update:party" or "update:party:contact" or is granted
record level access by the DA logic.
4. Define permission for users, not admins. Instead of looking for a
static permission, set the permission to be checked at the most
granular level. When doing so, admin users will always have permission
and the API will handle user access using DA logic.
-- see: http://docs.ofbiz.org/x/JR4
That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a
lot more details; interested parties are encouraged to read it through.
Andrew
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Adrian,
I will start a new thread to discuss this, but before I do I want to
make sure there isn't something I neglected to account for. Could you
please provide an example of such a service which uses SECA permission
services?
Andrew
On May 1, 2009, at 12:04 PM, Adrian Crum wrote:
> Andrew,
>
> I thought we were getting away from using the <required-permissions>
> element and using the <permission-service> element instead.
>
> If this type of change is made in other components, it will break a
> lot of code - because some components use permission service SECAs.
>
> -Adrian
>
> jaz@apache.org wrote:
>> Author: jaz
>> Date: Thu Apr 30 06:23:18 2009
>> New Revision: 770084
>> URL: http://svn.apache.org/viewvc?rev=770084&view=rev
>> Log:
>> Refactored Example Application to use new security mechanics - JIRA
>> OFBIZ-2392
>
> ...
>
>
>> Modified: ofbiz/trunk/framework/example/servicedef/services.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> --- ofbiz/trunk/framework/example/servicedef/services.xml (original)
>> +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr
>> 30 06:23:18 2009
>> @@ -27,29 +27,37 @@
>> <!-- Example & Related Services -->
>> <service name="createExample" default-entity-name="Example"
>> engine="entity-auto" invoke="create" auth="true">
>> <description>Create a Example</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="CREATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="create:example"/>
>> + </required-permissions> <auto-attributes
>> include="pk" mode="OUT" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> <override name="exampleTypeId" optional="false"/>
>> <override name="statusId" optional="false"/>
>> - <override name="exampleName" optional="false"/>
>> + <override name="exampleName" optional="false"/
>> > </service>
>> <service name="updateExample" default-entity-name="Example"
>> engine="entity-auto" invoke="update" auth="true">
>> <description>Update a Example</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="UPDATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="update:example:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> <attribute name="oldStatusId" type="String" mode="OUT"
>> optional="false"/>
>> </service>
>> <service name="deleteExample" default-entity-name="Example"
>> engine="entity-auto" invoke="delete" auth="true">
>> <description>Delete a Example</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="DELETE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="delete:example:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> </service>
>> <service name="createExampleStatus" default-entity-
>> name="ExampleStatus" engine="simple"
>> location="component://example/script/org/ofbiz/example/
>> example/ExampleServices.xml" invoke="createExampleStatus"
>> auth="true">
>> <description>Create a ExampleStatus</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="CREATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="update:example:status:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="all" mode="IN" optional="false">
>> <exclude field-name="statusDate"/>
>> <exclude field-name="statusEndDate"/>
>> @@ -58,7 +66,9 @@
>> <service name="createExampleItem" default-entity-
>> name="ExampleItem" engine="entity-auto" invoke="create" auth="true">
>> <description>Create a ExampleItem</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="CREATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="create:example:item:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> <override name="exampleItemSeqId" mode="OUT"/> <!-- make
>> this OUT rather than IN, we will automatically generate the next
>> sub-sequence ID -->
>> @@ -66,60 +76,78 @@
>> </service>
>> <service name="updateExampleItem" default-entity-
>> name="ExampleItem" engine="entity-auto" invoke="update" auth="true">
>> <description>Update a ExampleItem</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="UPDATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="update:example:item:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> </service>
>> <service name="deleteExampleItem" default-entity-
>> name="ExampleItem" engine="entity-auto" invoke="delete" auth="true">
>> <description>Delete a ExampleItem</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="DELETE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="delete:example:item:$
>> {exampleId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> </service>
>> <!-- ExampleFeature Services -->
>> <service name="createExampleFeature" default-entity-
>> name="ExampleFeature" engine="entity-auto" invoke="create"
>> auth="true">
>> <description>Create a ExampleFeature</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="CREATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="create:example:feature"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="OUT" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> <override name="description" optional="false"/>
>> </service>
>> <service name="updateExampleFeature" default-entity-
>> name="ExampleFeature" engine="entity-auto" invoke="update"
>> auth="true">
>> <description>Update a ExampleFeature</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="UPDATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="update:example:feature"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> </service>
>> <service name="deleteExampleFeature" default-entity-
>> name="ExampleFeature" engine="entity-auto" invoke="delete"
>> auth="true">
>> <description>Delete a ExampleFeature</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="DELETE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="delete:example:feature"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> </service>
>> <service name="createExampleFeatureAppl" default-entity-
>> name="ExampleFeatureAppl" engine="entity-auto" invoke="create"
>> auth="true">
>> <description>Create a ExampleFeatureAppl</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="CREATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="create:example:feature:$
>> {exampleFeatureId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> <override name="fromDate" optional="true"/>
>> </service>
>> <service name="updateExampleFeatureAppl" default-entity-
>> name="ExampleFeatureAppl" engine="entity-auto" invoke="update"
>> auth="true">
>> <description>Update a ExampleFeatureAppl</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="UPDATE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="update:example:feature:$
>> {exampleFeatureId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> <auto-attributes include="nonpk" mode="IN" optional="true"/>
>> </service>
>> <service name="deleteExampleFeatureAppl" default-entity-
>> name="ExampleFeatureAppl" engine="entity-auto" invoke="delete"
>> auth="true">
>> <description>Delete a ExampleFeatureAppl</description>
>> - <permission-service service-
>> name="exampleGenericPermission" main-action="DELETE"/>
>> + <required-permissions join-type="AND">
>> + <check-permission permission="delete:example:feature:$
>> {exampleFeatureId}"/>
>> + </required-permissions>
>> <auto-attributes include="pk" mode="IN" optional="false"/>
>> </service>
>> <!-- Permission Services -->
>> + <!-- @deprecated
>> <service name="exampleGenericPermission" engine="simple"
>> location="component://example/script/org/ofbiz/example/
>> ExamplePermissionServices.xml" invoke="exampleGenericPermission">
>> <implements service="permissionInterface"/>
>> </service>
>> + -->
>> <!-- Example ServiceTest Service -->
>> <service name="testCreateExampleService" engine="simple"
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/
data/ entitydef/ security/ servicedef/ widget/example/
Posted by Adrian Crum <ad...@hlmksw.com>.
Andrew,
I thought we were getting away from using the <required-permissions>
element and using the <permission-service> element instead.
If this type of change is made in other components, it will break a lot
of code - because some components use permission service SECAs.
-Adrian
jaz@apache.org wrote:
> Author: jaz
> Date: Thu Apr 30 06:23:18 2009
> New Revision: 770084
>
> URL: http://svn.apache.org/viewvc?rev=770084&view=rev
> Log:
> Refactored Example Application to use new security mechanics - JIRA OFBIZ-2392
...
> Modified: ofbiz/trunk/framework/example/servicedef/services.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
> ==============================================================================
> --- ofbiz/trunk/framework/example/servicedef/services.xml (original)
> +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30 06:23:18 2009
> @@ -27,29 +27,37 @@
> <!-- Example & Related Services -->
> <service name="createExample" default-entity-name="Example" engine="entity-auto" invoke="create" auth="true">
> <description>Create a Example</description>
> - <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleTypeId" optional="false"/>
> <override name="statusId" optional="false"/>
> - <override name="exampleName" optional="false"/>
> + <override name="exampleName" optional="false"/>
> </service>
> <service name="updateExample" default-entity-name="Example" engine="entity-auto" invoke="update" auth="true">
> <description>Update a Example</description>
> - <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <attribute name="oldStatusId" type="String" mode="OUT" optional="false"/>
> </service>
> <service name="deleteExample" default-entity-name="Example" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a Example</description>
> - <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
> <service name="createExampleStatus" default-entity-name="ExampleStatus" engine="simple"
> location="component://example/script/org/ofbiz/example/example/ExampleServices.xml" invoke="createExampleStatus" auth="true">
> <description>Create a ExampleStatus</description>
> - <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:status:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="all" mode="IN" optional="false">
> <exclude field-name="statusDate"/>
> <exclude field-name="statusEndDate"/>
> @@ -58,7 +66,9 @@
>
> <service name="createExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="create" auth="true">
> <description>Create a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:item:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleItemSeqId" mode="OUT"/> <!-- make this OUT rather than IN, we will automatically generate the next sub-sequence ID -->
> @@ -66,60 +76,78 @@
> </service>
> <service name="updateExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="update" auth="true">
> <description>Update a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:item:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleItem" default-entity-name="ExampleItem" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:item:${exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- ExampleFeature Services -->
> <service name="createExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="create" auth="true">
> <description>Create a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="description" optional="false"/>
> </service>
> <service name="updateExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="update" auth="true">
> <description>Update a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeature" default-entity-name="ExampleFeature" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <service name="createExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="create" auth="true">
> <description>Create a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature:${exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="fromDate" optional="true"/>
> </service>
> <service name="updateExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="update" auth="true">
> <description>Update a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission" main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature:${exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeatureAppl" default-entity-name="ExampleFeatureAppl" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission" main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature:${exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- Permission Services -->
> + <!-- @deprecated
> <service name="exampleGenericPermission" engine="simple"
> location="component://example/script/org/ofbiz/example/ExamplePermissionServices.xml" invoke="exampleGenericPermission">
> <implements service="permissionInterface"/>
> </service>
> + -->
>
> <!-- Example ServiceTest Service -->
> <service name="testCreateExampleService" engine="simple"
Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
Posted by David E Jones <jo...@apache.org>.
What is the point of changing all of the security data like this? In
other words, is there some reason that the new security stuff can't
use the same permissions syntax/convention as the older security stuff?
The thing to keep in mind is that not only will there be a big effort
to make all of these changes in OFBiz, but everyone with production
data will have to perform a big non-backward-compatible database
migration that will require system downtime.
It is certainly okay to require that if there is a good reason for it,
but I guess that's what I'm not seeing here... the benefits we all get
from the new format...
-David
On Apr 30, 2009, at 12:23 AM, jaz@apache.org wrote:
> Author: jaz
> Date: Thu Apr 30 06:23:18 2009
> New Revision: 770084
>
> URL: http://svn.apache.org/viewvc?rev=770084&view=rev
> Log:
> Refactored Example Application to use new security mechanics - JIRA
> OFBIZ-2392
>
> Added:
> ofbiz/trunk/framework/example/security/
> ofbiz/trunk/framework/example/security/CreateExample.groovy
> ofbiz/trunk/framework/example/security/UpdateExample.groovy
> Modified:
> ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> ofbiz/trunk/framework/example/entitydef/entitymodel.xml
> ofbiz/trunk/framework/example/ofbiz-component.xml
> ofbiz/trunk/framework/example/servicedef/services.xml
> ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml
> ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml
> ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml
>
> Modified: ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/config/ExampleUiLabels.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
> (original)
> +++ ofbiz/trunk/framework/example/config/ExampleUiLabels.xml Thu Apr
> 30 06:23:18 2009
> @@ -466,13 +466,13 @@
> <value xml:lang="it">DA FARE</value>
> </property>
> <property key="ExampleViewPermissionError">
> - <value xml:lang="en">You do not have permission to view
> this page. ("EXAMPLE_VIEW" or "EXAMPLE_ADMIN" needed)</value>
> - <value xml:lang="fr">Vous n'avez pas l'autorisation de voir
> cette page ("EXAMPLE_VIEW" ou "EXAMPLE_ADMIN" nécessaire)</value>
> - <value xml:lang="it">Tu non sei autorizzare a vedere questa
> pagina. (Permesso "EXAMPLE_VIEW" o "EXAMPLE_ADMIN" necessario)</value>
> - <value xml:lang="ro">Nu esti autorizat sa vezi aceasta
> pagina. (Este necesar Permisul "EXAMPLE_VIEW" sau "EXAMPLE_ADMIN")</
> value>
> - <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав длÑ
> пÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
> Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "EXAMPLE_VIEW" или "EXAMPLE_ADMIN")</value>
> - <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸
> à
> ¸
>
> à
> ¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹
> (หà¸à¹à¸² "EXAMPLE_VIEW" หรืภ"EXAMPLE_ADMIN"
> à¸à¸µà¹à¸à¹à¸ à¸à¸à¸²à¸£)</value>
> - <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé
> ¢çæéã(éè¦"EXAMPLE_VIEW"æ"EXAMPLE_ADMIN")</value>
> + <value xml:lang="en">You do not have permission to view
> this page. ("access:example" needed)</value>
> + <value xml:lang="fr">Vous n'avez pas l'autorisation de voir
> cette page ("access:example" nécessaire)</value>
> + <value xml:lang="it">Tu non sei autorizzare a vedere questa
> pagina. (Permesso "access:example" necessario)</value>
> + <value xml:lang="ro">Nu esti autorizat sa vezi aceasta
> pagina. (Este necesar Permisul "access:example")</value>
> + <value xml:lang="ru">У Ð²Ð°Ñ Ð½ÐµÑ Ð¿Ñав длÑ
> пÑоÑмоÑÑа ÑÑой ÑÑÑаниÑÑ. (необÑ
> Ð¾Ð´Ð¸Ð¼Ñ Ð¿Ñава "access:example")</value>
> + <value xml:lang="th">à¸à¸¸à¸à¹à¸¡à¹à¹à¸à¹à¸£à¸±à¸à¸
> à
> ¸
>
> à
> ¸¸à¸à¸²à¸à¹à¸«à¹à¹à¸à¹à¸²à¸à¸¹à¸«à¸à¹à¸²à¸à¸µà¹à¹à¸à¹
> (หà¸à¹à¸² "access:example" à¸à¸µà¹à¸à¹à¸ à¸à¸à¸²à¸£)</value>
> + <value xml:lang="zh">ä½ æ²¡ææµè§è¿ä¸ªé¡µé
> ¢çæéã(éè¦"access:example")</value>
> </property>
> <property key="ExampleWelcome">
> <value xml:lang="en">Welcome to the Example application!</
> value>
>
> Modified: ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/data/ExampleSecurityData.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/data/ExampleSecurityData.xml
> (original)
> +++ ofbiz/trunk/framework/example/data/ExampleSecurityData.xml Thu
> Apr 30 06:23:18 2009
> @@ -19,16 +19,30 @@
> -->
> <entity-engine-xml>
> <!-- Example security -->
> - <SecurityPermission description="View operations in the Example
> Management Screens." permissionId="EXAMPLE_VIEW"/>
> - <SecurityPermission description="Create operations in the
> Example Management Screens." permissionId="EXAMPLE_CREATE"/>
> - <SecurityPermission description="Update operations in the
> Example Management Screens." permissionId="EXAMPLE_UPDATE"/>
> - <SecurityPermission description="Delete operations in the
> Example Management Screens." permissionId="EXAMPLE_DELETE"/>
> - <SecurityPermission description="ALL operations in the Example
> Management Screens." permissionId="EXAMPLE_ADMIN"/>
> - <SecurityGroupPermission groupId="FULLADMIN"
> permissionId="EXAMPLE_ADMIN"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_CREATE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_DELETE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_UPDATE"/>
> - <SecurityGroupPermission groupId="FLEXADMIN"
> permissionId="EXAMPLE_VIEW"/>
> - <SecurityGroupPermission groupId="VIEWADMIN"
> permissionId="EXAMPLE_VIEW"/>
> - <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="EXAMPLE_ADMIN"/>
> + <SecurityPermission description="ACCESS the Example
> Application" permissionId="access:example"/>
> + <SecurityPermission description="CREATE operations in the
> Example Application" permissionId="create:example"
> dynamicAccess="component://example/security/CreateExample.groovy"/>
> + <SecurityPermission description="READ operations in the Example
> Application" permissionId="read:example"/>
> + <SecurityPermission description="UPDATE operations in the
> Example Application" permissionId="update:example"
> dynamicAccess="component://example/security/UpdateExample.groovy"/>
> + <SecurityPermission description="DELETE operations in the
> Example Application" permissionId="delete:example"/>
> +
> + <SecurityPermission description="CREATE STATUS operations in
> the Example Application" permissionId="create:example:status"/>
> + <SecurityPermission description="READ STATUS operations in the
> Example Application" permissionId="read:example:status"/>
> + <SecurityPermission description="UPDATE STATUS operations in
> the Example Application" permissionId="update:example:status"/>
> + <SecurityPermission description="DELETE STATUS operations in
> the Example Application" permissionId="delete:example:status"/>
> +
> + <SecurityPermission description="CREATE ITEM operations in the
> Example Application" permissionId="create:example:item"/>
> + <SecurityPermission description="READ ITEM operations in the
> Example Application" permissionId="read:example:item"/>
> + <SecurityPermission description="UPDATE ITEM operations in the
> Example Application" permissionId="update:example:item"/>
> + <SecurityPermission description="DELETE ITEM operations in the
> Example Application" permissionId="delete:example:item"/>
> +
> + <SecurityPermission description="CREATE FEATURE operations in
> the Example Application" permissionId="create:example:feature"/>
> + <SecurityPermission description="READ ITEM operations in the
> Example Application" permissionId="read:example:feature"/>
> + <SecurityPermission description="UPDATE ITEM operations in the
> Example Application" permissionId="update:example:feature"/>
> + <SecurityPermission description="DELETE ITEM operations in the
> Example Application" permissionId="delete:example:feature"/>
> +
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="access:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="create:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="read:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="update:example"/>
> + <SecurityGroupPermission groupId="BIZADMIN"
> permissionId="delete:example"/>
> </entity-engine-xml>
>
> Modified: ofbiz/trunk/framework/example/entitydef/entitymodel.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/entitydef/entitymodel.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/entitydef/entitymodel.xml (original)
> +++ ofbiz/trunk/framework/example/entitydef/entitymodel.xml Thu Apr
> 30 06:23:18 2009
> @@ -55,6 +55,7 @@
> <field name="exampleDate" type="date-time"></field>
> <field name="anotherDate" type="date-time"></field>
> <field name="anotherText" type="long-varchar"></field>
> + <field name="createdByUser" type="id-vlong-ne"></field>
> <prim-key field="exampleId"/>
> <relation type="one" fk-name="EXMPL_TYP" rel-entity-
> name="ExampleType">
> <key-map field-name="exampleTypeId"/>
> @@ -62,6 +63,9 @@
> <relation type="one" fk-name="EXMPL_STTS" rel-entity-
> name="StatusItem">
> <key-map field-name="statusId"/>
> </relation>
> + <relation type="one" fk-name="EXMPL_USER" rel-entity-
> name="UserLogin">
> + <key-map field-name="createdByUser" rel-field-
> name="userLoginId"/>
> + </relation>
> </entity>
> <entity entity-name="ExampleItem" package-
> name="org.ofbiz.example.example" title="Example Item Entity" default-
> resource-name="ExampleEntityLabels">
> <field name="exampleId" type="id-ne"></field>
>
> Modified: ofbiz/trunk/framework/example/ofbiz-component.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/ofbiz-component.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/ofbiz-component.xml (original)
> +++ ofbiz/trunk/framework/example/ofbiz-component.xml Thu Apr 30
> 06:23:18 2009
> @@ -54,6 +54,6 @@
> menu-name="secondary"
> server="default-server"
> location="webapp/example"
> - base-permission="OFBTOOLS,EXAMPLE"
> + base-permission="access:example"
> mount-point="/example"/>
> </ofbiz-component>
>
> Added: ofbiz/trunk/framework/example/security/CreateExample.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/CreateExample.groovy?rev=770084&view=auto
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/security/CreateExample.groovy
> (added)
> +++ ofbiz/trunk/framework/example/security/CreateExample.groovy Thu
> Apr 30 06:23:18 2009
> @@ -0,0 +1,21 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> + // this dynamic access grants ANYONE access
> + return true;
> \ No newline at end of file
>
> Added: ofbiz/trunk/framework/example/security/UpdateExample.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/security/UpdateExample.groovy?rev=770084&view=auto
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/security/UpdateExample.groovy
> (added)
> +++ ofbiz/trunk/framework/example/security/UpdateExample.groovy Thu
> Apr 30 06:23:18 2009
> @@ -0,0 +1,34 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> +import org.ofbiz.base.util.Debug;
> +
> +exampleId = permissionContext.get("exampleId");
> +Debug.logInfo("Groovy DA Context : " + permissionContext, "groovy");
> +Debug.logInfo("Calling UpdateExample.groovy - " + exampleId,
> "groovy");
> +if (exampleId != null) {
> + example = delegator.findOne("Example", [exampleId : exampleId],
> true);
> + Debug.logInfo("Example : " + example, "groovy");
> +
> + if (example.createdByUser == null ||
> userId.equals(example.createdByUser)) {
> + return true;
> + }
> +}
> +
> +return false;
>
> Modified: ofbiz/trunk/framework/example/servicedef/services.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/servicedef/services.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/servicedef/services.xml (original)
> +++ ofbiz/trunk/framework/example/servicedef/services.xml Thu Apr 30
> 06:23:18 2009
> @@ -27,29 +27,37 @@
> <!-- Example & Related Services -->
> <service name="createExample" default-entity-name="Example"
> engine="entity-auto" invoke="create" auth="true">
> <description>Create a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleTypeId" optional="false"/>
> <override name="statusId" optional="false"/>
> - <override name="exampleName" optional="false"/>
> + <override name="exampleName" optional="false"/>
> </service>
> <service name="updateExample" default-entity-name="Example"
> engine="entity-auto" invoke="update" auth="true">
> <description>Update a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <attribute name="oldStatusId" type="String" mode="OUT"
> optional="false"/>
> </service>
> <service name="deleteExample" default-entity-name="Example"
> engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a Example</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
> <service name="createExampleStatus" default-entity-
> name="ExampleStatus" engine="simple"
> location="component://example/script/org/ofbiz/example/
> example/ExampleServices.xml" invoke="createExampleStatus" auth="true">
> <description>Create a ExampleStatus</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:status:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="all" mode="IN" optional="false">
> <exclude field-name="statusDate"/>
> <exclude field-name="statusEndDate"/>
> @@ -58,7 +66,9 @@
>
> <service name="createExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="create" auth="true">
> <description>Create a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="exampleItemSeqId" mode="OUT"/> <!-- make
> this OUT rather than IN, we will automatically generate the next sub-
> sequence ID -->
> @@ -66,60 +76,78 @@
> </service>
> <service name="updateExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="update" auth="true">
> <description>Update a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleItem" default-entity-
> name="ExampleItem" engine="entity-auto" invoke="delete" auth="true">
> <description>Delete a ExampleItem</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:item:$
> {exampleId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- ExampleFeature Services -->
> <service name="createExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="create"
> auth="true">
> <description>Create a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="OUT" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="description" optional="false"/>
> </service>
> <service name="updateExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="update"
> auth="true">
> <description>Update a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeature" default-entity-
> name="ExampleFeature" engine="entity-auto" invoke="delete"
> auth="true">
> <description>Delete a ExampleFeature</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <service name="createExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="create"
> auth="true">
> <description>Create a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="CREATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="create:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> <override name="fromDate" optional="true"/>
> </service>
> <service name="updateExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="update"
> auth="true">
> <description>Update a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="UPDATE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="update:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> <auto-attributes include="nonpk" mode="IN" optional="true"/>
> </service>
> <service name="deleteExampleFeatureAppl" default-entity-
> name="ExampleFeatureAppl" engine="entity-auto" invoke="delete"
> auth="true">
> <description>Delete a ExampleFeatureAppl</description>
> - <permission-service service-name="exampleGenericPermission"
> main-action="DELETE"/>
> + <required-permissions join-type="AND">
> + <check-permission permission="delete:example:feature:$
> {exampleFeatureId}"/>
> + </required-permissions>
> <auto-attributes include="pk" mode="IN" optional="false"/>
> </service>
>
> <!-- Permission Services -->
> + <!-- @deprecated
> <service name="exampleGenericPermission" engine="simple"
> location="component://example/script/org/ofbiz/example/
> ExamplePermissionServices.xml" invoke="exampleGenericPermission">
> <implements service="permissionInterface"/>
> </service>
> + -->
>
> <!-- Example ServiceTest Service -->
> <service name="testCreateExampleService" engine="simple"
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> CommonScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/CommonScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/CommonScreens.xml
> Thu Apr 30 06:23:18 2009
> @@ -71,7 +71,7 @@
> <section>
> <condition>
> <and>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> <not><if-empty field="example"/
> ></not>
> </and>
> </condition>
> @@ -82,9 +82,9 @@
> </decorator-section>
> <decorator-section name="body">
> <section>
> - <!-- do check for EXAMPLE, _VIEW
> permission -->
> + <!-- do check for access:example
> permission -->
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <section>
> @@ -135,7 +135,7 @@
> <section>
> <condition>
> <and>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> <not><if-empty
> field="exampleFeature"/></not>
> </and>
> </condition>
> @@ -148,7 +148,7 @@
> <section>
> <!-- do check for EXAMPLE, _VIEW
> permission -->
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <section>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleAjaxScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> ExampleAjaxScreens.xml Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <container style="h1"><label>$
> {uiLabelMap[titleProperty]}</label></container>
> @@ -68,7 +68,7 @@
> <screen name="ListExampleFormOnly">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <!-- NOTE: these are needed because this may be run
> as a top level screen and would have no decorator -->
> @@ -84,7 +84,7 @@
> <screen name="CreateExampleFormOnly">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <!-- these are only needed so that when bsh
> evaluates use-when attributes these will exist and not cause an
> error -->
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleFeatureScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> ExampleFeatureScreens.xml Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <decorator-screen
> name="FindScreenDecorator" location="component://common/widget/
> CommonScreens.xml">
> @@ -98,7 +98,7 @@
> <screen name="LookupExampleFeature">
> <section>
> <condition>
> - <if-has-permission permission="EXAMPLE"
> action="_VIEW"/>
> + <if-has-permission permission="access:example"/>
> </condition>
> <actions>
> <property-map resource="ExampleUiLabels" map-
> name="uiLabelMap" global="true"/>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleForms.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleForms.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
> Thu Apr 30 06:23:18 2009
> @@ -142,6 +142,8 @@
> <field name="displayAnotherText" use-when="example!
> =null&&example.get("anotherText")!=null">
> <display description="${example.anotherText}"/>
> </field>
> + <field name="createdByUser" use-
> when="example==null"><hidden value="${userLogin.userLoginId}"/></
> field>
> + <field name="createdByUser" use-when="example!
> =null"><hidden/></field>
> <field name="submitButton" use-when="example==null" title="$
> {uiLabelMap.CommonCreate}"><submit button-type="button"/></field>
> <field name="submitButton" use-when="example!=null" title="$
> {uiLabelMap.CommonUpdate}"><submit button-type="button"/></field>
> </form>
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> ExampleScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> (original)
> +++ ofbiz/trunk/framework/example/widget/example/ExampleScreens.xml
> Thu Apr 30 06:23:18 2009
> @@ -34,7 +34,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <decorator-screen
> name="FindScreenDecorator" location="component://common/widget/
> CommonScreens.xml">
>
> Modified: ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/FormWidgetExampleScreens.xml?rev=770084&r1=770083&r2=770084&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml (original)
> +++ ofbiz/trunk/framework/example/widget/example/
> FormWidgetExampleScreens.xml Thu Apr 30 06:23:18 2009
> @@ -31,7 +31,7 @@
> <decorator-section name="body">
> <section>
> <condition>
> - <if-has-permission
> permission="EXAMPLE" action="_VIEW"/>
> + <if-has-permission
> permission="access:example"/>
> </condition>
> <widgets>
> <container style="h1"><label>$
> {uiLabelMap.PageTitleFormWidgetExamples}</label></container>
>
>