System Administrator's Guide |
![]() |
|||
About the APIs | ||||
These APIs are in the new AllCommerce 1.2 release. Visit http://www.zelerate.org/ often for documentation updates about the APIs. Database Extraction This section discusses the database extraction layer for release 1.2. This layer provides expanded database scalability. In order to support multiple databases, it is necessary to extract all database calls from scripts, and run them through an API. This allows for centralization of database access, which provides one location in which modifications can be made for various databases. This also allows for consistency of SQL syntax, and removes the likelihood of introducing errors within external scripts which could be hard to track down. As external applications interact with the database layer, the database layer will interact with the permissions layer. Each SQL subroutine will need to call a permissions layer 'check' routine prior to executing the query. Only queries which the user has acceptable permissions for will be executed, others will return undef to the calling script, indicating that there was a permissions problem. Not only are SQL calls going to be extracted, the method of executing the calls will also be extracted. Certain SQL results must be filtered after they are executed to only show the results that a user has permissions for. Therefore, a variety of retrieval routines will be provided, returning data in various data structures. Another improvement with having the database layer is that external scripts don't need to worry about what fits in the primary table, and what goes into the extraprop table. For the time being, the only overflow table that the database layer will automatically interact with is the extraprop table.
External Scripts should ONLY call the database layer. They should NEVER call the permissions layer. For more information, check http://www.zelerate.org/ for updates. See the Database Extraction Layer specification for additional technical details. Permissions This section gives you a technical perspective of the permissions layer. Fine control of what systems and subsystems can be used by different employees and groups is a prerequisite for the secure operation of a company running real-world enterprises. This specification describes the requirements and details of the permissions layer as well as its interaction with the other layers of the OS AllCommerce version 1.2 solution. Permission Levels Permissions have several levels. At the lowest level, you are starting with a system where "everything is allowed unless prohibited" (permissive) or the more conservative, where "nothing is allowed unless explicitly granted" (restrictive). Above the level discussed earlier are group permissions; a user may be a part of that group and inherit the group permissions. Finally, at the third level, there are permissions that belong to an individual. In a parallel, but totally separate set of permissions, certain objects in the system are "extremely secure," while others are "public". Thus a public resource may be visible to anyone, even if it is not specifically named in each user's permissions; this is a way to override the lowest level policies on a resource-by-resource basis. The Event Management System See www.zelerate.org for the latest information about the Event Management System. |
||||
|
||||
All Commerce User's Guide Table of Contents |