-
Notifications
You must be signed in to change notification settings - Fork 10
This version of CFTracker will be a rewrite of previous versions to better take advantage of lessons learnt and features that were tacked on as the project grew.
A clear and easy to use API should be created, this should allow building of interfaces to become much simpler as they should only make use of the API.
The API will require authorisation to use. CFTracker will provide the ability to create multiple API keys with customisable access to the API. This would allow multiple uses of the API but restrict possible actions. For example, an application may need to make use of certain session operations but need to be prevented from taking similar action against other applications.
Requiring an access key, this would provide access to CFTracker via a set or components in a similar manner to the Adobe ColdFusion AdminAPI
This would operate the same way as the local API, but with the additional security layer of encryption (incoming and outgoing) to prevent unauthorised access to the information.
Providing a secure method for communication is vital. Information should not be exposed or allow abuse of a template to perform unnecessary load on the server (request for stats should authenticate first, before considering anything else).
Each server could generate a Unique key during installation. The key would be manually provided to any external client (AIR, separate server etc...) and used to encrypt both incoming and outgoing requests. Encryption would be configurable, but limited to acceptable standards (CFML engine supported).
CFTracker would provide support for building hooks into the server, application and session scopes. These would have to match a set standard for providing details so CFTracker can automatically recognise them. Hooks would be functions, component methods and variables that would be displayed or perform a customised action.
application.cfcMaintain.maintenanceMode (variable, boolean, true / false). application.cfcMaintain.toggleMaintenance() (method, no parameters).
When given knowledge of the above, CFTracker would display the current value of the variable and a button to execute the "toggleMaintenance()" method.
Variables would be displayed or dumped if they are complex.
When provided with information about the methods or functions, CFTracker would build a small form to support its execution.
If it has arguments, form fields will be generated for the user to enter the required information. Complex variable entry (arrays, structures, xml etc...) may not be possible or limited.
The Server scope would contain a variable specifying what variables / functions / methods should be exposed in CFTracker and any special way of treating them (arguments, formatting, explanation text etc...).
The application scope would work in a similar manner to the Server scope. Additionally it would provide details of the variables / functions / methods contained within each session. This avoids each individual session containing the same information and avoids the overhead of CFTracker checking inside each session for specifications.
Notices, alerts and other such information should be configurable enough to set when user(s) would like to be informed. Should be built in such a way to be flexible and allow multiple methods of communication to be supported.
An obvious choice for providing information, the application would send emails to set addresses when required. This could also included daily reports as attachments or HTML formatted emails.
Set up the server (or central service) with a twitter account and it could provide short, to the point, updates on the servers status or alerts if something reaches a set limit. Would have to allow for the character limit and perhaps make use of URL shortening services to link back to the application (security risk?).
SMS, Database, custom template, URL (with parameters) etc...