You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Milind Parikh <mi...@gmail.com> on 2009/01/24 22:40:55 UTC
field level security in oFBiz
What is the best practice of implementing instance specific - field level
security in ofBiz?
servers can belong to different groups.
servers have a non-secure field called ip address
ip address can be viewed and updated by anyone.
servers have a secure field called notes.
These notes can be viewed only by person belonging to the
group managing the server.
server1 -- belongs to DBA group
server2 -- belongs to WebAdmin group
usrdba is a user belonging to DBA group
usrwedadmin is a user belonging to WebAdmin group
when usrdba logins, he can see both server1 and server2.
On server1
he sees both: ip address and
notes
On server2
he sees ONLY: ip address
One potential solution :
expose this as a service and embed the logic in the service.
I am leaning towards this option; because of upcoming REST API to ofBiz
would make use of this service
any others?
Regards
-- Milind
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fields in ofbiz are part of Entities.
the Actual Database is does not have any security accept that it is only
accessible on 127.0.0.1.
if other servers had db's, then need to be on the same class c and
behind the same router. The Ip would be like 10.x.x.x that is not
accessible from the internet side of the router.
Logins security is based on permissions and roles.
these are defined in each application, Service, and or UI.
the REST would be be an event thru the URI in the controller.
the event would convert the REST data to ofbiz services call to store
the data.
Milind Parikh sent the following on 1/24/2009 1:40 PM:
> What is the best practice of implementing instance specific - field level
> security in ofBiz?
>
> servers can belong to different groups.
>
> servers have a non-secure field called ip address
> ip address can be viewed and updated by anyone.
>
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> server1 -- belongs to DBA group
> server2 -- belongs to WebAdmin group
>
> usrdba is a user belonging to DBA group
> usrwedadmin is a user belonging to WebAdmin group
>
> when usrdba logins, he can see both server1 and server2.
> On server1
> he sees both: ip address and
> notes
> On server2
> he sees ONLY: ip address
>
>
> One potential solution :
> expose this as a service and embed the logic in the service.
> I am leaning towards this option; because of upcoming REST API to ofBiz
> would make use of this service
> any others?
>
> Regards
> -- Milind
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe44BrP3NbaWWqE4RAiuOAJ9LsaOPzUWc37iponRJXI8vFEvFMgCg0QGT
VIvDCeTMrLzpyewtH45PepM=
=qE6C
-----END PGP SIGNATURE-----
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I thinks that Data model confused the issue for someone that is coming
for a database back ground to use the word Tables instead of entities,
since we never get down to table level with ofbiz, accept as a storage
device. and though not recommend the datasource could be a xml file.
Jacques Le Roux sent the following on 1/24/2009 2:02 PM:
> Did you read http://docs.ofbiz.org/display/OFBTECH/OFBiz+security ?
>
> Jacques
>
> From: "Milind Parikh" <mi...@gmail.com>
>> What is the best practice of implementing instance specific - field level
>> security in ofBiz?
>>
>> servers can belong to different groups.
>>
>> servers have a non-secure field called ip address
>> ip address can be viewed and updated by anyone.
>>
>> servers have a secure field called notes.
>> These notes can be viewed only by person belonging to the
>> group managing the server.
>>
>> server1 -- belongs to DBA group
>> server2 -- belongs to WebAdmin group
>>
>> usrdba is a user belonging to DBA group
>> usrwedadmin is a user belonging to WebAdmin group
>>
>> when usrdba logins, he can see both server1 and server2.
>> On server1
>> he sees both: ip address
>> and
>> notes
>> On server2
>> he sees ONLY: ip address
>>
>>
>> One potential solution :
>> expose this as a service and embed the logic in the
>> service.
>> I am leaning towards this option; because of upcoming REST API to ofBiz
>> would make use of this service
>> any others?
>>
>> Regards
>> -- Milind
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe6UerP3NbaWWqE4RAmn8AJ9fkBD/qRwMVe8XxFxfjOm6EFyWVACfQ8i1
sOCcC7jSZg0G8zjMq6c0A08=
=gxl7
-----END PGP SIGNATURE-----
Re: field level security in oFBiz
Posted by Jacques Le Roux <ja...@les7arts.com>.
Did you read http://docs.ofbiz.org/display/OFBTECH/OFBiz+security ?
Jacques
From: "Milind Parikh" <mi...@gmail.com>
> What is the best practice of implementing instance specific - field level
> security in ofBiz?
>
> servers can belong to different groups.
>
> servers have a non-secure field called ip address
> ip address can be viewed and updated by anyone.
>
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> server1 -- belongs to DBA group
> server2 -- belongs to WebAdmin group
>
> usrdba is a user belonging to DBA group
> usrwedadmin is a user belonging to WebAdmin group
>
> when usrdba logins, he can see both server1 and server2.
> On server1
> he sees both: ip address and
> notes
> On server2
> he sees ONLY: ip address
>
>
> One potential solution :
> expose this as a service and embed the logic in the service.
> I am leaning towards this option; because of upcoming REST API to ofBiz
> would make use of this service
> any others?
>
> Regards
> -- Milind
>
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
why not follow my example of how ofbiz does this, I think you will get
your answer.
Milind Parikh sent the following on 1/24/2009 6:49 PM:
> I think that my example (of servers and notes) may not have been the
> clearest. Let me try once more (in context of orders and notes iso servers
> and notes).
>
> In the REST API,
> if I do
>
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders,
> I get
>
> <rfo:orders>
> <rfo:order id="002" plink="customer/1/order/002"/>
> <rfo:order id="003" plink="customer/1/order/003"/>
> </rfo:orders>
>
> Now if I am logged in as an ordinary user and
>
> I do
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> I should get
> <rfo:order
> id="002"
> product="ABC01"
> notes="************"
> />
>
> Now if I am logged in as an power user and
>
> I do
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> I should get
> <rfo:order
> id="002"
> product="ABC01"
> notes="PLEASE EXPEDIATE"
> />
>
>
> The net-net is to treat notes as a field of an entity and on an EXCEPTION
> basis, invoke the security rule (because otherwise this will not very
> efficient). The rows of a entity can be managed through the current ofbiz
> infrastructure. The question is: once the rows are identified, is there a
> clean and efficient ways of managing fields?
>
> The more fundamental question is : Is there a need to do this?
>
>
>
>
> On Sat, Jan 24, 2009 at 6:00 PM, BJ Freeman <bj...@free-man.net> wrote:
>
> here is how ofbiz handles this:
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
>
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
>
> a Delegator is assigned to a Datasource ,
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
> you can make a delegator Notes for instance and it is link to the server
> that has the Notes data.
>
> the delegator is assigned in the applications web.xml
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
> you would then have An Entity defined for Notes
> the Delegator will deal with an entity Notes. The services that do
> CRUD on Notes has the security.
> the Delegator is oblivious to where the Datasource Storage resides.
>
> Milind Parikh sent the following on 1/24/2009 1:40 PM:
>>>> What is the best practice of implementing instance specific - field level
>>>> security in ofBiz?
>>>>
>>>> servers can belong to different groups.
>>>>
>>>> servers have a non-secure field called ip address
>>>> ip address can be viewed and updated by anyone.
>>>>
>>>> servers have a secure field called notes.
>>>> These notes can be viewed only by person belonging to the
>>>> group managing the server.
>>>>
>>>> server1 -- belongs to DBA group
>>>> server2 -- belongs to WebAdmin group
>>>>
>>>> usrdba is a user belonging to DBA group
>>>> usrwedadmin is a user belonging to WebAdmin group
>>>>
>>>> when usrdba logins, he can see both server1 and server2.
>>>> On server1
>>>> he sees both: ip address
> and
>>>> notes
>>>> On server2
>>>> he sees ONLY: ip address
>>>>
>>>>
>>>> One potential solution :
>>>> expose this as a service and embed the logic in the
> service.
>>>> I am leaning towards this option; because of upcoming REST API to ofBiz
>>>> would make use of this service
>>>> any others?
>>>>
>>>> Regards
>>>> -- Milind
>>>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe9SzrP3NbaWWqE4RAmAjAJwIkYXRWdxc66Bqs6W0F5Q0ocpghACggqRP
gaMjPJRbFuSBuUzWph/027Y=
=WGuz
-----END PGP SIGNATURE-----
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
we have some examples of interfacing with other system in the
specialpurpose.
so my suggestion is you use ofbiz in it native mode and create a
interface to Android-gphone using rest.
in this senario, you would field a Rest request
http://ofbizlocalhost:8443/Android/control/
you would use Apache server to field the REST and do a mod_rewrite to
the parse the REST URL into an ofbiz URL.
then your event service can pass back to the Android the REST response
that is built out of ofbiz entities.
You do have your hands full on how to accomplish this.
Milind Parikh sent the following on 1/24/2009 7:16 PM:
> I am aware that REST is not supported OOTB into ofBiz. This is an effort to
> get REST into ofBiz (primarily because I need REST to work with Android -
> the gPhone). The URL would not "login" (against REST to maintain states).
> Fortunately the dispatcher code has thought through this exact possibility
> and accepts login, password as an accepted means. The rest-for-ofbiz
> componet would intercept the http request, go through the dispatcher to
> execute and send results back to the caller.
>
> It is hard to explain the design in a paragraph; but hope this makes sense.
> Thanks for the help !!
>
>
> Regards
> -- Milind
>
> On Sat, Jan 24, 2009 at 7:06 PM, BJ Freeman <bj...@free-man.net> wrote:
>
> first Not sure what the URL is, if it is representing an ofbiz url,
> is does not support REST OOTB.
> if this is something that ofbiz is suppose to read and parse then a
> service would be called, that then goes to
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders
> and gets a response of
> <rfo:orders>
> <rfo:order id="002" plink="customer/1/order/002"/>
> <rfo:order id="003" plink="customer/1/order/003"/>
> </rfo:orders>
> then the service would parse this and put it in to ofbiz.
> if this URL needs to be login to, then the service would have to do
> this, as an interface to the external REST system.
>
>
> Milind Parikh sent the following on 1/24/2009 6:49 PM:
>>>> I think that my example (of servers and notes) may not have been the
>>>> clearest. Let me try once more (in context of orders and notes iso
> servers
>>>> and notes).
>>>>
>>>> In the REST API,
>>>> if I do
>>>>
>>>> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders,
>>>> I get
>>>>
>>>> <rfo:orders>
>>>> <rfo:order id="002" plink="customer/1/order/002"/>
>>>> <rfo:order id="003" plink="customer/1/order/003"/>
>>>> </rfo:orders>
>>>>
>>>> Now if I am logged in as an ordinary user and
>>>>
>>>> I do
>>>> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
>>>> I should get
>>>> <rfo:order
>>>> id="002"
>>>> product="ABC01"
>>>> notes="************"
>>>> />
>>>>
>>>> Now if I am logged in as an power user and
>>>>
>>>> I do
>>>> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
>>>> I should get
>>>> <rfo:order
>>>> id="002"
>>>> product="ABC01"
>>>> notes="PLEASE EXPEDIATE"
>>>> />
>>>>
>>>>
>>>> The net-net is to treat notes as a field of an entity and on an EXCEPTION
>>>> basis, invoke the security rule (because otherwise this will not very
>>>> efficient). The rows of a entity can be managed through the current ofbiz
>>>> infrastructure. The question is: once the rows are identified, is there a
>>>> clean and efficient ways of managing fields?
>>>>
>>>> The more fundamental question is : Is there a need to do this?
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jan 24, 2009 at 6:00 PM, BJ Freeman <bj...@free-man.net> wrote:
>>>>
>>>> here is how ofbiz handles this:
>>>> servers have a secure field called notes.
>>>> These notes can be viewed only by person belonging to the
>>>> group managing the server.
>>>>
>>>> <delegator name="default" entity-model-reader="main"
>>>> entity-group-reader="main" entity-eca-reader="main"
>>>> distributed-cache-clear-enabled="false">
>>>> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
>>>> <group-map group-name="org.ofbiz.olap"
>>>> datasource-name="localderbyolap"/>
>>>> </delegator>
>>>>
>>>>
>>>> <context-param>
>>>> <param-name>entityDelegatorName</param-name>
>>>> <param-value>default</param-value>
>>>> <description>The Name of the Entity Delegator to use, defined in
>>>> entityengine.xml</description>
>>>> </context-param>
>>>>
>>>>
>>>> a Delegator is assigned to a Datasource ,
>>>>
>>>> <delegator name="default" entity-model-reader="main"
>>>> entity-group-reader="main" entity-eca-reader="main"
>>>> distributed-cache-clear-enabled="false">
>>>> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
>>>> <group-map group-name="org.ofbiz.olap"
>>>> datasource-name="localderbyolap"/>
>>>> </delegator>
>>>>
>>>> you can make a delegator Notes for instance and it is link to the server
>>>> that has the Notes data.
>>>>
>>>> the delegator is assigned in the applications web.xml
>>>> <context-param>
>>>> <param-name>entityDelegatorName</param-name>
>>>> <param-value>default</param-value>
>>>> <description>The Name of the Entity Delegator to use, defined in
>>>> entityengine.xml</description>
>>>> </context-param>
>>>>
>>>> you would then have An Entity defined for Notes
>>>> the Delegator will deal with an entity Notes. The services that do
>>>> CRUD on Notes has the security.
>>>> the Delegator is oblivious to where the Datasource Storage resides.
>>>>
>>>> Milind Parikh sent the following on 1/24/2009 1:40 PM:
>>>>>>> What is the best practice of implementing instance specific - field
> level
>>>>>>> security in ofBiz?
>>>>>>>
>>>>>>> servers can belong to different groups.
>>>>>>>
>>>>>>> servers have a non-secure field called ip address
>>>>>>> ip address can be viewed and updated by anyone.
>>>>>>>
>>>>>>> servers have a secure field called notes.
>>>>>>> These notes can be viewed only by person belonging to
> the
>>>>>>> group managing the server.
>>>>>>>
>>>>>>> server1 -- belongs to DBA group
>>>>>>> server2 -- belongs to WebAdmin group
>>>>>>>
>>>>>>> usrdba is a user belonging to DBA group
>>>>>>> usrwedadmin is a user belonging to WebAdmin group
>>>>>>>
>>>>>>> when usrdba logins, he can see both server1 and server2.
>>>>>>> On server1
>>>>>>> he sees both: ip
> address
>>>> and
>>>>>>> notes
>>>>>>> On server2
>>>>>>> he sees ONLY: ip
> address
>>>>>>>
>>>>>>> One potential solution :
>>>>>>> expose this as a service and embed the logic in the
>>>> service.
>>>>>>> I am leaning towards this option; because of upcoming REST API to
> ofBiz
>>>>>>> would make use of this service
>>>>>>> any others?
>>>>>>>
>>>>>>> Regards
>>>>>>> -- Milind
>>>>>>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe9wDrP3NbaWWqE4RAt82AKCuc3I1QV3NTXrSZ5M0WJMVjPnRPwCfUQKy
4KNEvAmlSLJkpB1vlZLU+04=
=amgD
-----END PGP SIGNATURE-----
Re: field level security in oFBiz
Posted by Milind Parikh <mi...@gmail.com>.
I am aware that REST is not supported OOTB into ofBiz. This is an effort to
get REST into ofBiz (primarily because I need REST to work with Android -
the gPhone). The URL would not "login" (against REST to maintain states).
Fortunately the dispatcher code has thought through this exact possibility
and accepts login, password as an accepted means. The rest-for-ofbiz
componet would intercept the http request, go through the dispatcher to
execute and send results back to the caller.
It is hard to explain the design in a paragraph; but hope this makes sense.
Thanks for the help !!
Regards
-- Milind
On Sat, Jan 24, 2009 at 7:06 PM, BJ Freeman <bj...@free-man.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> first Not sure what the URL is, if it is representing an ofbiz url,
> is does not support REST OOTB.
> if this is something that ofbiz is suppose to read and parse then a
> service would be called, that then goes to
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders
> and gets a response of
> <rfo:orders>
> <rfo:order id="002" plink="customer/1/order/002"/>
> <rfo:order id="003" plink="customer/1/order/003"/>
> </rfo:orders>
> then the service would parse this and put it in to ofbiz.
> if this URL needs to be login to, then the service would have to do
> this, as an interface to the external REST system.
>
>
> Milind Parikh sent the following on 1/24/2009 6:49 PM:
> > I think that my example (of servers and notes) may not have been the
> > clearest. Let me try once more (in context of orders and notes iso
> servers
> > and notes).
> >
> > In the REST API,
> > if I do
> >
> > http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders,
> > I get
> >
> > <rfo:orders>
> > <rfo:order id="002" plink="customer/1/order/002"/>
> > <rfo:order id="003" plink="customer/1/order/003"/>
> > </rfo:orders>
> >
> > Now if I am logged in as an ordinary user and
> >
> > I do
> > http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> > I should get
> > <rfo:order
> > id="002"
> > product="ABC01"
> > notes="************"
> > />
> >
> > Now if I am logged in as an power user and
> >
> > I do
> > http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> > I should get
> > <rfo:order
> > id="002"
> > product="ABC01"
> > notes="PLEASE EXPEDIATE"
> > />
> >
> >
> > The net-net is to treat notes as a field of an entity and on an EXCEPTION
> > basis, invoke the security rule (because otherwise this will not very
> > efficient). The rows of a entity can be managed through the current ofbiz
> > infrastructure. The question is: once the rows are identified, is there a
> > clean and efficient ways of managing fields?
> >
> > The more fundamental question is : Is there a need to do this?
> >
> >
> >
> >
> > On Sat, Jan 24, 2009 at 6:00 PM, BJ Freeman <bj...@free-man.net> wrote:
> >
> > here is how ofbiz handles this:
> > servers have a secure field called notes.
> > These notes can be viewed only by person belonging to the
> > group managing the server.
> >
> > <delegator name="default" entity-model-reader="main"
> > entity-group-reader="main" entity-eca-reader="main"
> > distributed-cache-clear-enabled="false">
> > <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> > <group-map group-name="org.ofbiz.olap"
> > datasource-name="localderbyolap"/>
> > </delegator>
> >
> >
> > <context-param>
> > <param-name>entityDelegatorName</param-name>
> > <param-value>default</param-value>
> > <description>The Name of the Entity Delegator to use, defined in
> > entityengine.xml</description>
> > </context-param>
> >
> >
> > a Delegator is assigned to a Datasource ,
> >
> > <delegator name="default" entity-model-reader="main"
> > entity-group-reader="main" entity-eca-reader="main"
> > distributed-cache-clear-enabled="false">
> > <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> > <group-map group-name="org.ofbiz.olap"
> > datasource-name="localderbyolap"/>
> > </delegator>
> >
> > you can make a delegator Notes for instance and it is link to the server
> > that has the Notes data.
> >
> > the delegator is assigned in the applications web.xml
> > <context-param>
> > <param-name>entityDelegatorName</param-name>
> > <param-value>default</param-value>
> > <description>The Name of the Entity Delegator to use, defined in
> > entityengine.xml</description>
> > </context-param>
> >
> > you would then have An Entity defined for Notes
> > the Delegator will deal with an entity Notes. The services that do
> > CRUD on Notes has the security.
> > the Delegator is oblivious to where the Datasource Storage resides.
> >
> > Milind Parikh sent the following on 1/24/2009 1:40 PM:
> >>>> What is the best practice of implementing instance specific - field
> level
> >>>> security in ofBiz?
> >>>>
> >>>> servers can belong to different groups.
> >>>>
> >>>> servers have a non-secure field called ip address
> >>>> ip address can be viewed and updated by anyone.
> >>>>
> >>>> servers have a secure field called notes.
> >>>> These notes can be viewed only by person belonging to
> the
> >>>> group managing the server.
> >>>>
> >>>> server1 -- belongs to DBA group
> >>>> server2 -- belongs to WebAdmin group
> >>>>
> >>>> usrdba is a user belonging to DBA group
> >>>> usrwedadmin is a user belonging to WebAdmin group
> >>>>
> >>>> when usrdba logins, he can see both server1 and server2.
> >>>> On server1
> >>>> he sees both: ip
> address
> > and
> >>>> notes
> >>>> On server2
> >>>> he sees ONLY: ip
> address
> >>>>
> >>>>
> >>>> One potential solution :
> >>>> expose this as a service and embed the logic in the
> > service.
> >>>> I am leaning towards this option; because of upcoming REST API to
> ofBiz
> >>>> would make use of this service
> >>>> any others?
> >>>>
> >>>> Regards
> >>>> -- Milind
> >>>>
> >>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJe9cjrP3NbaWWqE4RAlKNAKCPYXs4XjtofwpD9Cx7Wi7089Y08wCgq1eQ
> zH5gXumaH0N5s6KOdvCgr+E=
> =UvdH
> -----END PGP SIGNATURE-----
>
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
first Not sure what the URL is, if it is representing an ofbiz url,
is does not support REST OOTB.
if this is something that ofbiz is suppose to read and parse then a
service would be called, that then goes to
http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders
and gets a response of
<rfo:orders>
<rfo:order id="002" plink="customer/1/order/002"/>
<rfo:order id="003" plink="customer/1/order/003"/>
</rfo:orders>
then the service would parse this and put it in to ofbiz.
if this URL needs to be login to, then the service would have to do
this, as an interface to the external REST system.
Milind Parikh sent the following on 1/24/2009 6:49 PM:
> I think that my example (of servers and notes) may not have been the
> clearest. Let me try once more (in context of orders and notes iso servers
> and notes).
>
> In the REST API,
> if I do
>
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders,
> I get
>
> <rfo:orders>
> <rfo:order id="002" plink="customer/1/order/002"/>
> <rfo:order id="003" plink="customer/1/order/003"/>
> </rfo:orders>
>
> Now if I am logged in as an ordinary user and
>
> I do
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> I should get
> <rfo:order
> id="002"
> product="ABC01"
> notes="************"
> />
>
> Now if I am logged in as an power user and
>
> I do
> http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
> I should get
> <rfo:order
> id="002"
> product="ABC01"
> notes="PLEASE EXPEDIATE"
> />
>
>
> The net-net is to treat notes as a field of an entity and on an EXCEPTION
> basis, invoke the security rule (because otherwise this will not very
> efficient). The rows of a entity can be managed through the current ofbiz
> infrastructure. The question is: once the rows are identified, is there a
> clean and efficient ways of managing fields?
>
> The more fundamental question is : Is there a need to do this?
>
>
>
>
> On Sat, Jan 24, 2009 at 6:00 PM, BJ Freeman <bj...@free-man.net> wrote:
>
> here is how ofbiz handles this:
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
>
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
>
> a Delegator is assigned to a Datasource ,
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
> you can make a delegator Notes for instance and it is link to the server
> that has the Notes data.
>
> the delegator is assigned in the applications web.xml
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
> you would then have An Entity defined for Notes
> the Delegator will deal with an entity Notes. The services that do
> CRUD on Notes has the security.
> the Delegator is oblivious to where the Datasource Storage resides.
>
> Milind Parikh sent the following on 1/24/2009 1:40 PM:
>>>> What is the best practice of implementing instance specific - field level
>>>> security in ofBiz?
>>>>
>>>> servers can belong to different groups.
>>>>
>>>> servers have a non-secure field called ip address
>>>> ip address can be viewed and updated by anyone.
>>>>
>>>> servers have a secure field called notes.
>>>> These notes can be viewed only by person belonging to the
>>>> group managing the server.
>>>>
>>>> server1 -- belongs to DBA group
>>>> server2 -- belongs to WebAdmin group
>>>>
>>>> usrdba is a user belonging to DBA group
>>>> usrwedadmin is a user belonging to WebAdmin group
>>>>
>>>> when usrdba logins, he can see both server1 and server2.
>>>> On server1
>>>> he sees both: ip address
> and
>>>> notes
>>>> On server2
>>>> he sees ONLY: ip address
>>>>
>>>>
>>>> One potential solution :
>>>> expose this as a service and embed the logic in the
> service.
>>>> I am leaning towards this option; because of upcoming REST API to ofBiz
>>>> would make use of this service
>>>> any others?
>>>>
>>>> Regards
>>>> -- Milind
>>>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe9cjrP3NbaWWqE4RAlKNAKCPYXs4XjtofwpD9Cx7Wi7089Y08wCgq1eQ
zH5gXumaH0N5s6KOdvCgr+E=
=UvdH
-----END PGP SIGNATURE-----
Re: field level security in oFBiz
Posted by Milind Parikh <mi...@gmail.com>.
I think that my example (of servers and notes) may not have been the
clearest. Let me try once more (in context of orders and notes iso servers
and notes).
In the REST API,
if I do
http://127.0.0.1:8080/rest-for-ofbiz/customer/1/orders,
I get
<rfo:orders>
<rfo:order id="002" plink="customer/1/order/002"/>
<rfo:order id="003" plink="customer/1/order/003"/>
</rfo:orders>
Now if I am logged in as an ordinary user and
I do
http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
I should get
<rfo:order
id="002"
product="ABC01"
notes="************"
/>
Now if I am logged in as an power user and
I do
http://127.0.0.1:8080/rest-for-ofbiz/customer/1/order/002"
I should get
<rfo:order
id="002"
product="ABC01"
notes="PLEASE EXPEDIATE"
/>
The net-net is to treat notes as a field of an entity and on an EXCEPTION
basis, invoke the security rule (because otherwise this will not very
efficient). The rows of a entity can be managed through the current ofbiz
infrastructure. The question is: once the rows are identified, is there a
clean and efficient ways of managing fields?
The more fundamental question is : Is there a need to do this?
On Sat, Jan 24, 2009 at 6:00 PM, BJ Freeman <bj...@free-man.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> here is how ofbiz handles this:
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
>
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
>
> a Delegator is assigned to a Datasource ,
>
> <delegator name="default" entity-model-reader="main"
> entity-group-reader="main" entity-eca-reader="main"
> distributed-cache-clear-enabled="false">
> <group-map group-name="org.ofbiz" datasource-name="localderby"/>
> <group-map group-name="org.ofbiz.olap"
> datasource-name="localderbyolap"/>
> </delegator>
>
> you can make a delegator Notes for instance and it is link to the server
> that has the Notes data.
>
> the delegator is assigned in the applications web.xml
> <context-param>
> <param-name>entityDelegatorName</param-name>
> <param-value>default</param-value>
> <description>The Name of the Entity Delegator to use, defined in
> entityengine.xml</description>
> </context-param>
>
> you would then have An Entity defined for Notes
> the Delegator will deal with an entity Notes. The services that do
> CRUD on Notes has the security.
> the Delegator is oblivious to where the Datasource Storage resides.
>
> Milind Parikh sent the following on 1/24/2009 1:40 PM:
> > What is the best practice of implementing instance specific - field level
> > security in ofBiz?
> >
> > servers can belong to different groups.
> >
> > servers have a non-secure field called ip address
> > ip address can be viewed and updated by anyone.
> >
> > servers have a secure field called notes.
> > These notes can be viewed only by person belonging to the
> > group managing the server.
> >
> > server1 -- belongs to DBA group
> > server2 -- belongs to WebAdmin group
> >
> > usrdba is a user belonging to DBA group
> > usrwedadmin is a user belonging to WebAdmin group
> >
> > when usrdba logins, he can see both server1 and server2.
> > On server1
> > he sees both: ip address
> and
> > notes
> > On server2
> > he sees ONLY: ip address
> >
> >
> > One potential solution :
> > expose this as a service and embed the logic in the
> service.
> > I am leaning towards this option; because of upcoming REST API to ofBiz
> > would make use of this service
> > any others?
> >
> > Regards
> > -- Milind
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJe8fWrP3NbaWWqE4RAuO7AJ9sx54BZV4SXsOijeMIANewqd+69gCgmbOM
> /82Z4G38QymSj+xzrS4IfX4=
> =krJK
> -----END PGP SIGNATURE-----
>
Re: field level security in oFBiz
Posted by BJ Freeman <bj...@free-man.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
here is how ofbiz handles this:
servers have a secure field called notes.
These notes can be viewed only by person belonging to the
group managing the server.
<delegator name="default" entity-model-reader="main"
entity-group-reader="main" entity-eca-reader="main"
distributed-cache-clear-enabled="false">
<group-map group-name="org.ofbiz" datasource-name="localderby"/>
<group-map group-name="org.ofbiz.olap"
datasource-name="localderbyolap"/>
</delegator>
<context-param>
<param-name>entityDelegatorName</param-name>
<param-value>default</param-value>
<description>The Name of the Entity Delegator to use, defined in
entityengine.xml</description>
</context-param>
a Delegator is assigned to a Datasource ,
<delegator name="default" entity-model-reader="main"
entity-group-reader="main" entity-eca-reader="main"
distributed-cache-clear-enabled="false">
<group-map group-name="org.ofbiz" datasource-name="localderby"/>
<group-map group-name="org.ofbiz.olap"
datasource-name="localderbyolap"/>
</delegator>
you can make a delegator Notes for instance and it is link to the server
that has the Notes data.
the delegator is assigned in the applications web.xml
<context-param>
<param-name>entityDelegatorName</param-name>
<param-value>default</param-value>
<description>The Name of the Entity Delegator to use, defined in
entityengine.xml</description>
</context-param>
you would then have An Entity defined for Notes
the Delegator will deal with an entity Notes. The services that do
CRUD on Notes has the security.
the Delegator is oblivious to where the Datasource Storage resides.
Milind Parikh sent the following on 1/24/2009 1:40 PM:
> What is the best practice of implementing instance specific - field level
> security in ofBiz?
>
> servers can belong to different groups.
>
> servers have a non-secure field called ip address
> ip address can be viewed and updated by anyone.
>
> servers have a secure field called notes.
> These notes can be viewed only by person belonging to the
> group managing the server.
>
> server1 -- belongs to DBA group
> server2 -- belongs to WebAdmin group
>
> usrdba is a user belonging to DBA group
> usrwedadmin is a user belonging to WebAdmin group
>
> when usrdba logins, he can see both server1 and server2.
> On server1
> he sees both: ip address and
> notes
> On server2
> he sees ONLY: ip address
>
>
> One potential solution :
> expose this as a service and embed the logic in the service.
> I am leaning towards this option; because of upcoming REST API to ofBiz
> would make use of this service
> any others?
>
> Regards
> -- Milind
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJe8fWrP3NbaWWqE4RAuO7AJ9sx54BZV4SXsOijeMIANewqd+69gCgmbOM
/82Z4G38QymSj+xzrS4IfX4=
=krJK
-----END PGP SIGNATURE-----