Ean, When I implemented a test case using the new JSON service event handler I found that the requests behaved just like any other HTTP request. The security part is transparent, you require auth (but not HTTPS) for events which will be Ajax-Enabled. This uses the user login object found in the session (due to the fact that the url for the Ajax request is wrapped around <@ofbizUrl> tags) and the service engine handles the security.
For screen based (non-JSON) responses, I think the security handling should be up to the page returned, just like any other page in OFBiz. Thoughts? Andrew Ean Schuessler wrote: > On Wednesday 13 December 2006 19:21, David E Jones wrote: >> BTW, as to how I see AJAX stuff fitting into OFBiz there are 2 big >> parts: >> >> 1. adding dynamic client side features to the form and screen (and >> other) widgets for things like dynamic lookups, expanding tree- >> browsers, movable screen-lets, etc. >> >> 2. special purpose pages that are meant to optimize a certain task, >> like the checkout stuff Tim mentioned, but probably even moreso for >> fancy back-end stuff >> >> For #1 replacing an AJAX framework is easy, but doesn't make as big a >> different in coding efficiency or anything, whereas for #2 something >> better would make coding easier, but require more rewriting... > > We've had a few discussions going on over here about how to handle AJAX > integration while still keeping security in mind. It seems like providing a > limited dispatcher that only allows certain groups of services to be invoked > is a good thing. Lots of services are already userLogin and Role protected, > which is a good headstart. Maybe a specific AJAX dispatcher that has only > services which are already vetted exposed through it? > > It would also be nice to have a high level facility for invoking those > services and then triggering their results to something like the Dojo event > framework when they return. With something like Comet these events could even > be initiated by the server as if you had made a call on the client and then > the delivery events occured. >
smime.p7s
Description: S/MIME Cryptographic Signature
