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 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 > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJe44BrP3NbaWWqE4RAiuOAJ9LsaOPzUWc37iponRJXI8vFEvFMgCg0QGT VIvDCeTMrLzpyewtH45PepM= =qE6C -----END PGP SIGNATURE----- |
Administrator
|
In reply to this post by Milind P
Did you read http://docs.ofbiz.org/display/OFBTECH/OFBiz+security ?
Jacques From: "Milind Parikh" <[hidden email]> > 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 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" <[hidden email]> >> 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 >> > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJe6UerP3NbaWWqE4RAmn8AJ9fkBD/qRwMVe8XxFxfjOm6EFyWVACfQ8i1 sOCcC7jSZg0G8zjMq6c0A08= =gxl7 -----END PGP SIGNATURE----- |
In reply to this post by Milind P
-----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 > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJe8fWrP3NbaWWqE4RAuO7AJ9sx54BZV4SXsOijeMIANewqd+69gCgmbOM /82Z4G38QymSj+xzrS4IfX4= =krJK -----END PGP SIGNATURE----- |
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 <[hidden email]> 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----- > |
-----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 <[hidden email]> 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----- |
In reply to this post by Milind P
-----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 <[hidden email]> 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----- |
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 <[hidden email]> 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 <[hidden email]> 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----- > |
-----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 <[hidden email]> 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 <[hidden email]> 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----- |
Free forum by Nabble | Edit this page |