Back-End admins with FB?

Thought I'd try this question again sine things are quiet now and everyone ignored me during the flap about XFB Standards: ======================================= Thought I'd tap the knowledge out there on how you guys handle administration of various circuit applications and the central application. Alot of times you want to write circuit applications so that they can be re-used in other applications.  In addition, alot of modules have administrators associated with them which manage content, data that the user normally doesn't have access or has controlled/granular access to.  Anyway I was wondering how you people handle administration in FuseBox.  Whether you do it on a circuit by circuit level or do you write an admin circuit which manages all the security and the admin fuseactions.  Furthermore, how do you provide standardized security for the circuits and their fuses.  I know we've seen the example where including the act_secure.cfm from the security circuit provides the security.  I suppose if you adhere to this standard or any standard you're okay.  I've always liked a centralized admin, others seems to embed the admininistration into each circuit/app. Goal: To create an application-wide administrator that centralizes site administration One Idea: ========= Create a file that is a plain HTML menu (dsp_admin.cfm) that triggers the various fuses like:   <b>User Functions<b><BR>   <a href="/secure/index.cfm?fuseaction=adduser">Add User</a><BR>   <a href="/secure/index.cfm?fuseaction=deluser">Delete User</a><BR> Then have a script which crawls the applications looking for these dsp_admin.cfm files and incorporate them dynamically into an admin center. What are others doing out there? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Ben,     Not to long ago I was thinking about the need for modularity and control of the admin as well.  I think varying phases of the ideas I have hit me at different times, but I think I have a pretty good idea of how to do this and I plan to try it out on a personal project over the next couple of months. Actually I have a couple of ideas.     The first idea is to build a module table in the database, and then to build admin screens to correspond.  You would need to know a few things about the modules, for instance file path and name of the index.cfm for that module, module name, whether or not it should run in your admin wrapper (or front-end wrapper if it is a front-end module), perhaps a flag indicating if it is fuseboxed or not, fuseaction to call the module,  and security access rights for the module.  I'm generally in favor of security access levels or groups if you will, and thus I would put together a cross-reference table for connecting the modules to what groups/members have access to it.     I've also considered using "mod_" files that would go in a directory called "modules" and have the mod files store information on the module, thinks like where its main file is, param's, and so on.  It would probably be a good place to add notes, such as what is needed to run the module and so on.   Then you could have your main index file search the module directory and use the mod names to build your admin links. But I think what I like best is to combine the the database idea and the mod file idea so that you can implement security by the module, developer's could create the "mod_" files which would store meaningful details of the modules, and the module admin section could read this information in when loading in a new module. For instance a mod file might contain: mod_name = "Module Name" mod_version = "0.42" mod_author = "C. F. Coder" mod_created_date = 05/26/2001 mod_index = "index.cfm"        (I think  mod_fusebox  would also be a good name) mod_default_dir = "moddemo" and so on.  I like the idea of doing something like this so that I can say build a shell of a system, then include particular modules depending on the client, and heck I could even sell them add-ons in the future. I think I would also created one fuseaction that stood for modules, we'll call it mod, and all module links would include their module number or id (whichever your prefer) which will let us query the database in an action file and grab the appropriate include file.  So a URL might look like: < a href="#self#?fuseaction=mod&muid=12">#mod_name#</a > .... (on into our fuseactions)     <cfcase value="mod">         <!--- Grab our module index file --->         <cfinclude template="qry/qry_getModIndex.cfm">         <!--- Make sure we got a record --->         <cfif getModIndex.recordcount GT 1>             <cfoutput query="getModIndex.cfm">             <cfinclude template="#mod_path#/#mod_index#">             </cfoutput>         </cfif>     </cfcase> Obviously the code would probably need a little more tweaking than what I have there, but its just an example of how it could work.  You might would even want to call it as a module instead of a include.  So it might be <cf_#mod_name#> or something similar.  The would probably work better as you could even pass in variables inside the calling tag.  All of that info could be stored in the database, along with say what fuseactions are valid for that module.  I might would also introduce MFA's, module-fuseactions, or as I like to use, SFA's (sub-fuseaction's), to send commands into the module, though it may not be necessary depending on how you have your backed written and how the modules interact with one another. Any how I'm sure other's have far better ideas, those are just some thoughts that have been floating around in my head on the subject. Good luck! Ted Ben Koshy wrote: ----- Excess quoted text cut - see Original Post for more ----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Ben,     Not to long ago I was thinking about the need for modularity and control of the admin as well.  I think varying phases of the ideas I have hit me at different times, but I think I have a pretty good idea of how to do this and I plan to try it out on a personal project over the next couple of months. Actually I have a couple of ideas.     The first idea is to build a module table in the database, and then to build admin screens to correspond.  You would need to know a few things about the modules, for instance file path and name of the index.cfm for that module, module name, whether or not it should run in your admin wrapper (or front-end wrapper if it is a front-end module), perhaps a flag indicating if it is fuseboxed or not, fuseaction to call the module, and security access rights for the module.  I'm generally in favor of security access levels or groups if you will, and thus I would put together a cross-reference table for connecting the modules to what groups/members have access to it.     I've also considered using "mod_" files that would go in a directory called "modules" and have the mod files store information on the module, thinks like where its main file is, param's, and so on.  It would probably be a good place to add notes, such as what is needed to run the module and so on.  Then you could have your main index file search the module directory and use the mod names to build your admin links.  But I think what I like best is to combine the the database idea and the mod file idea so that you can implement security by the module, developer's could create the "mod_" files which would store meaningful details of the modules, and the module admin section could read this information in when loading in a new module. For instance a mod file might contain: mod_name = "Module Name" mod_version = "0.42" mod_author = "C. F. Coder" mod_created_date = 05/26/2001 mod_index = "index.cfm"        (I think  mod_fusebox  would also be a good name) mod_default_dir = "moddemo" and so on.  I like the idea of doing something like this so that I can say build a shell of a system, then include particular modules depending on the client, and heck I could even sell them add-ons in the future. I think I would also created one fuseaction that stood for modules, we'll call it mod, and all module links would include their module number or id (whichever your prefer) which will let us query the database in an action file and grab the appropriate include file.  So a URL might look like: < a href="#self#?fuseaction=mod&muid=12">#mod_name#</a > ..... (on into our fuseactions)     <cfcase value="mod">         <cfinclude template="act/act_runMod.cfm">     </cfcase> .... inside of act_runMod.cfm might look something like:          <!--- Grab our module index file --->         <cfinclude template="../qry/qry_getModIndex.cfm">         <!--- Make sure we got a record --->         <cfif getModIndex.recordcount GT 1>             <cfoutput query="getModIndex.cfm">             <cfif mod_security = 1>                 <cfinclude template="act_checkSecurityLevel.cfm">             </cfif>             <cfinclude template="#mod_path#/#mod_index#">             </cfoutput>         </cfif> Obviously the code would probably need a little more tweaking than what I have there, but its just an example of how it could work.  You might would even want to call it as a module instead of a include.  So it might be <cf_#mod_name#> or something similar.  The would probably work better as you could even pass in variables inside the calling tag.  All of that info could be stored in the database, along with say what fuseactions are valid for that module.  I might would also introduce MFA's, module-fuseactions, or as I like to use, SFA's (sub-fuseaction's), to send commands into the module, though it may not be necessary depending on how you have your backed written and how the modules interact with one another. Any how I'm sure other's have far better ideas, those are just some thoughts that have been floating around in my head on the subject. Good luck! Ted Ben Koshy wrote: ----- Excess quoted text cut - see Original Post for more ----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Ben,     Not to long ago I was thinking about the need for modularity and control of the admin as well.  I think varying phases of the ideas I have hit me at different times, but I think I have a pretty good idea of how to do this and I plan to try it out on a personal project over the next couple of months. Actually I have a couple of ideas.     The first idea is to build a module table in the database, and then to build admin screens to correspond.  You would need to know a few things about the modules, for instance file path and name of the index.cfm for that module, module name, whether or not it should run in your admin wrapper (or front-end wrapper if it is a front-end module), perhaps a flag indicating if it is fuseboxed or not, fuseaction to call the module, and security access rights for the module.  I'm generally in favor of security access levels or groups if you will, and thus I would put together a cross-reference table for connecting the modules to what groups/members have access to it.     I've also considered using "mod_" files that would go in a directory called "modules" and have the mod files store information on the module, thinks like where its main file is, param's, and so on.  It would probably be a good place to add notes, such as what is needed to run the module and so on.   Then you could have your main index file search the module directory and use the mod names to build your admin links. But I think what I like best is to combine the the database idea and the mod file idea so that you can implement security by the module, developer's could create the "mod_" files which would store meaningful details of the modules, and the module admin section could read this information in when loading in a new module. For instance a mod file might contain: mod_name = "Module Name" mod_version = "0.42" mod_author = "C. F. Coder" mod_created_date = 05/26/2001 mod_index = "index.cfm"        (I think  mod_fusebox  would also be a good name) mod_default_dir = "moddemo" and so on.  I like the idea of doing something like this so that I can say build a shell of a system, then include particular modules depending on the client, and heck I could even sell them add-ons in the future. I think I would also created one fuseaction that stood for modules, we'll call it mod, and all module links would include their module number or id (whichever your prefer) which will let us query the database in an action file and grab the appropriate include file.  So a URL might look like: < a href="#self#?fuseaction=mod&muid=12">#mod_name#</a > ...... (on into our fuseactions)     <cfcase value="mod">         <cfinclude template="act/act_runMod.cfm">     </cfcase> ..... inside of act_runMod.cfm might look something like:          <!--- Grab our module index file --->         <cfinclude template="../qry/qry_getModIndex.cfm">         <!--- Make sure we got a record --->         <cfif getModIndex.recordcount GT 1>             <cfoutput query="getModIndex.cfm">             <cfif mod_security = 1>                 <cfinclude template="act_checkSecurityLevel.cfm">             </cfif>             <cfinclude template="#mod_path#/#mod_index#">             </cfoutput>         </cfif> Obviously the code would probably need a little more tweaking than what I have there, but its just an example of how it could work.  You might would even want to call it as a module instead of a include.  So it might be <cf_#mod_name#> or something similar.  The would probably work better as you could even pass in variables inside the calling tag.  All of that info could be stored in the database, along with say what fuseactions are valid for that module.  I might would also introduce MFA's, module-fuseactions, or as I like to use, SFA's (sub-fuseaction's), to send commands into the module, though it may not be necessary depending on how you have your backed written and how the modules interact with one another. Any how I'm sure other's have far better ideas, those are just some thoughts that have been floating around in my head on the subject. Good luck! Ted Ben Koshy wrote: ----- Excess quoted text cut - see Original Post for more ----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

We have a "standard" admin plug in to add/edit users and assign rights to them based on an AdminRights table in the db. When you select a user the app displays a dynamic list of rights which can be assigned as check boxes. This is very flexible as for each application you just change the list of rights in the db of that application and voila the admin now shows these rights. Then in Index.cfm you can control access to each and every circuit or fuseaction action by verifying the user has the needed rights. We use binary masks and the bitAnd function as the applications don't need more than 31 different rights. But for a completely flexible system use unique ID's for each right and list functions. HTH, Noam     Sent:  Saturday, 26 May 2001 23:40   To:  Fusebox   Subject:  Back-End admins with FB?   Thought I'd try this question again sine things are quiet now and everyone   ignored me during the flap about XFB Standards:   =======================================   Thought I'd tap the knowledge out there on how you guys handle   administration of various circuit applications and the central application.   Alot of times you want to write circuit applications so that they can be   re-used in other applications.  In addition, alot of modules have   administrators associated with them which manage content, data that the user   normally doesn't have access or has controlled/granular access to. Anyway I   was wondering how you people handle administration in FuseBox. Whether you   do it on a circuit by circuit level or do you write an admin circuit which   manages all the security and the admin fuseactions.  Furthermore, how do you   provide standardized security for the circuits and their fuses.  I know   we've seen the example where including the act_secure.cfm from the security   circuit provides the security.  I suppose if you adhere to this standard or   any standard you're okay.  I've always liked a centralized admin, others   seems to embed the admininistration into each circuit/app.   Goal: To create an application-wide administrator that centralizes site   administration   One Idea:   =========   Create a file that is a plain HTML menu (dsp_admin.cfm) that triggers the   various fuses like:     <b>User Functions<b><BR>     <a href="/secure/index.cfm?fuseaction=adduser">Add User</a><BR>     <a href="/secure/index.cfm?fuseaction=deluser">Delete User</a><BR>   Then have a script which crawls the applications looking for these   dsp_admin.cfm files and incorporate them dynamically into an admin center.   What are others doing out there? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm