Gentlemen,

Good news. I made the recommended underscore change and both the

<check-permission permission="LEARN" action="_VIEW"/> and <check-permission
permission="LEARN" action="_ADMIN"/>

examples worked. Thanks for that!

However, in the next example under the Role Checks section, I hit a new
problem.

I changed my service definition to look like

    <service name="learningCallingServiceOneWithPermission" engine="java"
location="org.ofbiz.learning.learning.LearningServices"
invoke="callingServiceOne">
        <description>First Service Called From The Controller</description>
        <required-permissions join-type="OR">
            <check-role-member role-type="CUSTOMER"/>
        </required-permissions>
        <implements service="learningInterface"/>
    </service>

In ModelPermission.java I also commented out

    partyRoles = EntityUtil.filterByDate(partyRoles);

which is now on line 109, and rebuilt.

I tried with line 109 both commented and uncommented, but in neither case
was either 'allowed' or 'denied' able to invoke the service.

Any suggestions?

Regarding the bug bush, we are currently reviewing a couple of different
frameworks, so if we decide to go with OFBiz, I'll let you know.

PS. I should point out that I am reading the online version of the book at
Safari Books. I'm not sure how the books get on there so maybe the
underscore was some sort of OCR error?
PPS. Also, I've found that whenever there's a URL or URI somewhere in
example code, it adds a whitespace character in the middle of it, e.g.
below:

<screen name="ProcessEntityAccessBSF">
    <section>
        <actions>
            <script location="component://learning/webapp/learning/
WEB-INF/actions/entityaccess/processEntityAccessBSF.bsh"/>
        </actions>
        <widgets>
            <decorator-screen name="main-decorator"
location="${parameters.mainDecoratorLocation}">
                <decorator-section name="title">
                    <label text="Generic Screen for Displaying Data
Retrieved"/>
                </decorator-section>
                <decorator-section name="body">
                    <include-form name="ScriptNameForm"
location="component://learning/widget/ learning/LearningForms.xml"/>
                    <section>
                        <condition><not> <if-empty
field-name="parameters.scriptName"/> </not></condition>
                        <widgets>
                            <platform-specific><html>
                                <html-template
location="component://learning/webapp/
learning/entityaccess/displaydataretrieved.ftl"/>
                            </html></platform-specific>
                        </widgets>
                    </section>
                </decorator-section>
            </decorator-screen>
        </widgets>
    </section>
</screen>

I haven't worked out the pattern of when it appears, and it wasn't a major
issue. Just mildly annoying, but it could cause confusion for novice users.


On 18 June 2015 at 14:12, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
>
> Guys like you are welcome, we could even have a bug bash sometimes
https://en.wikipedia.org/wiki/Bug_bash
>
> Jacques
>
>
> Le 18/06/2015 12:57, Brad Smith a écrit :
>>
>> Merci!
>>
>> I will have a bash at it again when I get home tonight. Don't be too hard
>> on yourself. I am notorious for being thorough and annoying because of
it.
>> :) I am sure I pay for my sins in other ways... :p
>>
>> Will let you know how I get on.
>>
>> On 18 June 2015 at 05:42, Jacques Le Roux <jacques.le.r...@les7arts.com>
>> wrote:
>>
>>> Le 16/06/2015 13:49, Brad Smith a écrit :
>>>
>>>> My bad, the question should rather be, is two-part permissions approach
>>>> deprecated?
>>>>
>>> Actually no, it's still usable, look for "check-permission" at
>>>
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference
>>> Note that to effectively work it needs to be followed by a
>>> <check-permission> as explained here
>>> http://markmail.org/message/dnlrev5pnj7brhfm
>>>
>>> As a reviewer of this book, I'm embarrassed to say it, but after 8 years
>>> you clearly found a typo, the underscore is missing. As looking for
>>> examples in OFBiz shows, it should be
>>>      <check-permission permission="LEARN" action="_VIEW"/>
>>>
>>> If you are interested in more details about OFBiz Security Permissions
the
>>> reference so far is
>>>
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Permissions
>>> that I completely rewrote last year.
>>>
>>> Jacques
>>>
>>>
>>>
>>>> On 16 June 2015 at 13:43, Brad Smith <wheninf...@gmail.com> wrote:
>>>>
>>>>   Hi all,
>>>>>
>>>>> I am currently running through Apache OFBiz Development: The
Beginner's
>>>>> Tutorial by Howell and Wong.
>>>>>
>>>>> I have my dev environment setup in IntelliJ and so far the examples
have
>>>>> all more-or-less worked. I am up to Chapter 11, Permissions and the
>>>>> Service
>>>>> Engine and have hit some issues.
>>>>>
>>>>> The example setup in the "learning" component is as follows:
>>>>>
>>>>> ${component:learning}\servicedef\services.xml
>>>>> ---------------------------------------------
>>>>>
>>>>> <service name="learningCallingServiceOneWithPermission" engine="java"
>>>>> location="org.ofbiz.learning.learning.LearningServices"
>>>>> invoke="callingServiceOne">
>>>>> <description>First Service Called From The Controller</description>
>>>>> <required-permissions join-type="OR">
>>>>> <check-permission permission="LEARN_VIEW"/>
>>>>> </required-permissions>
>>>>> <implements service="learningInterface"/>
>>>>> </service>
>>>>>
>>>>> ${webapp:learning}\WEB-INF\controller.xml
>>>>> -----------------------------------------
>>>>>
>>>>> <request-map uri="TestPermissions">
>>>>> <security auth="true" https="true"/>
>>>>> <response name="success" type="view"
>>>>> value="TestCallingServicesWithPermission"/>
>>>>> <response name="error" type="view" value="login"/>
>>>>> </request-map>
>>>>> <request-map uri="TestCallingServicesWithPermission">
>>>>> <security auth="true" https="true"/>
>>>>> <event type="service"
invoke="learningCallingServiceOneWithPermission"/>
>>>>> <response name="success" type="view"
>>>>> value="TestCallingServicesWithPermission"/>
>>>>> <response name="error" type="view"
>>>>> value="TestCallingServicesWithPermission"/>
>>>>> </request-map>
>>>>>
>>>>> and
>>>>>
>>>>> <view-map name="TestCallingServicesWithPermission" type="screen"
>>>>>
>>>>>
page="component://learning/widget/learning/LearningScreens.xml#TestCallingServicesWithPermission"/>
>>>>>
>>>>> ${component:learning}\widget\learning\LearningScreens.xml
>>>>> ---------------------------------------------------------
>>>>>
>>>>> <screen name="TestFirstService">
>>>>>       <section>
>>>>>           <widgets>
>>>>>               <section>
>>>>>                   <condition><if-empty
>>>>> field-name="formTarget"/></condition>
>>>>>                   <actions>
>>>>>                       <set field="formTarget"
value="TestFirstService"/>
>>>>>                       <set field="title" value="Testing Our First
>>>>> Service"/>
>>>>>                   </actions>
>>>>>                   <widgets/>
>>>>>               </section>
>>>>>               <decorator-screen name="main-decorator"
>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>                   <decorator-section name="body">
>>>>>                       <include-form name="TestingServices"
>>>>> location="component://learning/widget/learning/LearningForms.xml"/>
>>>>>                       <label text="Full Name:
${parameters.fullName}"/>
>>>>>                   </decorator-section>
>>>>>               </decorator-screen>
>>>>>           </widgets>
>>>>>       </section>
>>>>> </screen>
>>>>> ...
>>>>> <screen name="TestCallingServicesWithPermission">
>>>>>       <section>
>>>>>           <actions><set field="formTarget"
>>>>> value="TestCallingServicesWithPermission"/>
>>>>>           </actions>
>>>>>           <widgets>
>>>>>               <include-screen name="TestFirstService"/>
>>>>>           </widgets>
>>>>>       </section>
>>>>> </screen>
>>>>>
>>>>> ${component:learning}\widget\learning\LearningForms.xml
>>>>> -------------------------------------------------------
>>>>>
>>>>> <form name="TestingServices" type="single" target="${formTarget}">
>>>>>       <field name="firstName"><text/></field>
>>>>>       <field name="lastName"><text/></field>
>>>>>       <field name="planetId"><text/></field>
>>>>>       <field name="submit"><submit/></field>
>>>>> </form>
>>>>>
>>>>> With regards to permissions, I have them set up as follows as per
Chapter
>>>>> 9:
>>>>>
>>>>> User            Security Group        SecurityPermission
>>>>> User/Security Group From Date          User/Security Group Thru Date
>>>>>
>>>>>
>>>>>
-------------------------------------------------------------------------------------------------------------------------------------
>>>>> allowed         LEARNSCREENS          LEARN_VIEW
>>>>> 2015-06-15 19:34:15.832                NULL
>>>>> denied          LEARNSCREENS          LEARN_VIEW
>>>>> 2015-06-13 18:57:44.724                2015-06-13 18:57:44.724
>>>>>     "             LEARNSCREENS          LEARN_VIEW
>>>>> 2015-06-13 18:57:44.000                2015-06-13 19:33:47.000
>>>>>
>>>>> Under the above configuration, the permissions checks work as
advertised,
>>>>> and "allowed" is able to call the service while "denied" is not.
>>>>>
>>>>> The next section of the chapter talks about two-part permissions, and
>>>>> makes the following changes to the configuration. Apparently, OFBiz is
>>>>> supposed to interpret the underscore in permission attribute as some
sort
>>>>> of tokenising character, where the first token "LEARN" becomes the
>>>>> permission, and the second part "VIEW" becomes an action. This seems
>>>>> "loose" to me but nevertheless.
>>>>>
>>>>> ${component:learning}\servicedef\services.xml
>>>>> ---------------------------------------------
>>>>>
>>>>> <check-permission permission="LEARN_VIEW"/>
>>>>>
>>>>> becomes
>>>>>
>>>>> <check-permission permission="LEARN" action="VIEW"/>
>>>>>
>>>>> According to the text, the authorisation behaviour should remain
exactly
>>>>> the same. In other words, the check-permission elements are
equivalent.
>>>>> But
>>>>> this is not the case. Under the modified configuration, neither
"allowed"
>>>>> nor "denied" are able to call the service. I also don't see a "LEARN"
>>>>> item
>>>>> in the SecurityPermission entity anywhere, so I don't see how this
should
>>>>> work in the first place.
>>>>>
>>>>> Is this tokenised approach deprecated? Or is there something else
going
>>>>> on?
>>>>>
>>>>>

Reply via email to