Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/

[jonesde]

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, [hidden email] 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&amp;&amp;example.get(&quot;anotherText&quot;)!=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>
>
>

[Andrew Zeneski-2]

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

[Adrian Crum]

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

[Andrew Zeneski-2]

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

[Jacopo Cappellato-4]

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

[Adrian Crum]

<set field="hasPermission" value="${(hasPermission['update:context1'] ||
hasPermission['update:context2']) &amp;&amp;
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
>
>

[Jacopo Cappellato-4]

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']) &amp;&amp;  
> 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

[Adrian Crum]

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']) &amp;&amp;
>> 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
>

[Jacopo Cappellato-4]

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']) &amp;&amp;  
>>> 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

[Adrian Crum]

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']) &amp;&amp;
>>>> 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
>

[Jacques Le Roux]

From: "Andrew Zeneski" <[hidden email]>
> 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

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> 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']) &amp;&amp;
>>>>> 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
>>
>

[Andrew Zeneski-2]

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" <[hidden email]>
>> 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
>

[Andrew Zeneski-2]

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.

[Andrew Zeneski-2]

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

[Adrian Crum]

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.
>
>

[David E Jones-3]

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

[Adrian Crum]

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

[David E Jones-3]

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

[Adrian Crum]

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
>
>