3) Why wouldn't you just wrap the whole lot into extdirect.cfc?
Most of the functionality is wrapped inside of Direct.cfm. Initially i had this implemented as a single Application.cfc file which you could drop inside a "service" directory and then it handled all sorts of things such as security etc. However, I thought that this would be too limiting to many users and refactored it into the 3 file structure it is now.
Originally Posted by dawesi
4) At what level would you apply your security context, as some people may not have permission to various pages, so you would have to then remove objects referencing items you don't want people to see. Also sometimes you don't want people to know every method that is available, you then need to create a security proxy for the server-side code? How would you suggest going about this.
You can customize what is sent down to the client via any application specific logic that you want. This could be a new custom attribute such as a Role like "Administrator", "Moderator", "User" or it could be something more fine grained such as the users userId and a complex set of permissions that are stored in a db/file system/web service call somewhere.
Perhaps this would be best done by allowing users to provide a filter in Direct.cfc getAPIScript immediately before outputting the API spec. What do you think?
EDIT: As I posted above the invokeCall method in the CFC should be checking to make sure that ExtDirect attribute is set on both the CFC and Method.
As another poster mentioned all of your other security constraints should be handled at the server-side just like we've done in the past in a typical Ajax app.
Last edited by aconran; 13 May 2009 at 7:01 AM.
Reason: added some stuff...