Changes between Version 9 and Version 10 of FeddPluginCalls

Timestamp:

Jun 29, 2010 11:06:26 AM (14 years ago)

Author:

faber

Comment:

--

FeddPluginCalls

@@ -17 +17 @@
 
 This is not an interface from the experiment controller, but we discuss it to mention the tools available for implementors.  These include routines to save state and interpret the standard parts of the [FeddDatabases#AccessComponentAccessDB access database], including specializing for testbed dependent data.  The method {{{read_access(file, local_info_parser)}}} takes the file to read and a function that takes the string following the access attribute and returns the local testbed attributes, stored into the self.access dict, keyed by the [FeddAbout#GlobalIdentifiers:Three-levelNames three-name] being authorized.  The {{{___init___()}}} routine of source:fedd/trunk/federation/skeleton_access.py federation.skeleton_access] includes an example of this.
+
+The base class also creates {{{self.auth}}}, which is an [source:fedd/trunk/federation/authorizer.py authorizer object].  This object keeps track of the authorization attributes associated with the three-level names and fedids that the plug-in knows.  When reading the authorization database, the base class assigns the attributes given by the attribute field of the database to the relevant names.  Generally this will an '''access''' attribute tp three-level names allowed to make allocations.  Other attributes can be added by the plug-in, and the authorizer used to control acces to them.  The [source:fedd/trunk/federation/skeleton_access.py skeleton plug-in] includes code to do ths.
 
 In addition, the initializer of the [source:fedd/trunk/federation/access.py federation.access] base class parses standard parameters from {{{[access]}}} section from the configuration file.  The fields and corresponding class instance attributes are:
@@ -50 +52 @@
 
 The !RequestAccess command asks the testbed to map the [FeddAbout#GlobalIdentifiers:Three-levelNames three-level name] on the call into local permissions and to do any bookkeeping associated with later attachment of resources to that allocation.  Specifically, a [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Fedids fedid] must be created.  Requests from this allocation back to the central experiment controller will be made under that principal/fedid.  Such requests gather configuration information or parameters passed between sub-experiments during creation.  The per-allocation fedid allows fine-grained control of access to thie information at the experiment controller, as well as the ability to name (and therefore request operation on) the various allocations made on this plug-in.
+
+The plug-in should add an authorization attribute to the creator of the allocation that indicates that the creator can manipulate the allocation via any of the other commands.  Existing plug-ins do this by adding an attribute with the same value as the allocation's fedid to the [source:fedd/trunk/federation/authorizer.py authorization object].
 
 A !RequestAccess message has the following format: