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