These are drop-in libraries for adding an API endpoint to a Flamework project.
It includes libraries and webpages for dispatching API requests and responses as well as creating and managing API keys.
There is also support for authenticated API methods using cookies (not really useful for third-party things) and OAuth2 access tokens (which means you've got a site that uses SSL).
You can either install all of the files manually or you can the bin/setup.sh
script which will install most of the relevant bits automatically and make a
note of the stuff you'll see need to do yourself.
You will need to copy the contents of the flamework-api .htaccess file in your projects's .htaccess file. Take a look at it and be sure to notice all the stuff that's been commented out at the top.
It's a lot of hoop-jumping to separate API calls (api.example.com/rest) from all the other user-level administrative pages (example.com/api/methods) and to make sure things that need to be done over SSL are (like OAuth2). By default it's all commented out because what do I know about your webserver is configured. So spend a couple minutes looking at all this stuff and thinking about it and adjusting accordingly. Also: remember all the security around OAuth2 is predicated around the use of SSL.
Otherwise all the URLs defined in the .htaccess file are discussed below.
A boolean flag indicating whether or not the API is available for use.
A boolean flag indicating whether or not documentation for API methods is publicly available.
A boolean flag indicating whether or not to log API requests.
Currently these are just written to the Apache error logs. Eventually it might be a configurable thing that allows to store things in Redis, etc. But right now it's not.
This currently doesn't actually do anything. But, you know, throttling! (See above inre: logging.)
The fully-qualified URL of the API endpoint.
You should leave this blank as it will be set automatically in api_config_init()
The fully-qualified URL of the site that exposes the API endpoint. These may not
be the same. See the api_subdomain parameter below.
You should leave this blank as it will be set automatically in api_config_init()
Optionally define a sub-domain for your API. For example api.my-website.com
Where clients using the API should send requests. Note that this is really defined (controlled) in the .htaccess file but is included here in order to generate API documentation.
A boolean flag indicating whether or not the API requires SSL. This is used to
generate api_abs_root_url and site_abs_root_url.
Irrelevant if you are using OAuth2 (below) otherwise a boolean flag indicating whether API methods must be called with a registered API key.
A boolean flag indicating whether or not to allow users to create new API keys.
A boolean flag indicating whether or not to allow users (and applications) to create new authentication (access) tokens.
Currently supported auth types are oauth2 and cookies.
A boolean flag indicating whether or not to allow users to magically create both API keys and auth (access) tokens for themselves without all the usual hoop-jumping of delegated auth.
An optional flag to require that people pass OAuth2 access tokens around in the HTTP Authentication header.
Allow people to make OAuth2 requests using the HTTP GET method. There are couple of things you need to be aware of if you enable this:
-
You can (and should) still control whether or not a given method must be called using a different HTTP method. See below for details.
-
You should not enable this unless you're using HTTPS. You really shouldn't be using OAuth2 at all without HTTPS but I can't control that (and by the time that the code here might notice the disconnect it will be too late).
Site keys are special API keys that are not bound to any user and are created with an explicit time to live (ttl). They are retrieved (or created) when the web site is loaded and checked to make sure they don't need to automatically expired.
Normally there's no reason for your code to see (or use) site keys. Instead your code might check a site "token", as in an access token used for delegated authentication. Site tokens are minted when the page loads and bind the current site API key with the current user.
That means a separate site token is created for each user and a shared site token (with limited permissions) is created for logged-out users. Like site keys the tokens are given a finite time to live (ttl) which is defined below.
All of this allows your website to use its own API the same way every other application does without having to force users jump through the usual authentication dance.
A boolean flag controlling whether site keys are enabled.
A boolean flag controlling whether site tokens are enabled. Note that site tokens won't work unless site keys are enabled.
The time to live for site keys. Default is 28800 seconds, or 8 hours.
The time to live for site tokens for logged-out users. Default is 28800 seconds, or 8 hours.
The time to live for site tokens for logged-in users. Default is 3600 seconds, or 1 hours.
Here's the annoying part.
In order for this to work you'll need to modify the code in init.php for this
to work. The relevant code is included below and in the
www/include/init.php.site-keys file.
Go and look for the following:
if ($this_is_webpage){
login_check_login();
And then add:
# API site key/token stuff
if (features_is_enabled("api")){
loadlib("api");
if (features_is_enabled(array("api_site_keys", "api_site_tokens"))){
loadlib("api_keys");
loadlib("api_oauth2_access_tokens");
$token = api_oauth2_access_tokens_fetch_site_token($GLOBALS['cfg']['user']);
$GLOBALS['smarty']->assign_by_ref("site_token", $token['access_token']);
}
}
A few things to notice:
-
The part where we're adding the site keys/tokens code after we call
login_check_login -
The part where we're checking that the API itself is enabled.
-
The part where OAuth2 tokens are hard-coded. That will need to be revisited if another delegated auth token system is supported. Right not it's the only game so...
-
The part where the token is being assigned to a Smarty variable. How your code uses that variable is left up to you. Specifically if you're calling the API you will need to grab the Smarty variable
site_tokenand pass it along with each request.
Finally, having to modify init.php really sucks. It works but it's neither
great nor elegant. Any suggestions for making this better are welcome.
The default number of results to return, per page, for things that are paginated.
The maximum number of results to return, per page, for things that are paginated.
API methods, and related specifics, are defined as a dictionary where the keys are method names and the values are the method details.
For example:
$GLOBALS['cfg']['api']['methods'] => array(
"api.spec.methods" => array(
"description" => "Return the list of available API response methods.",
"documented" => 1,
"enabled" => 1,
"library" => "api_spec"
"parameters" => array(
array("name" => "method_class", "description" => "Only return methods contained by this method class", "required" => 0),
),
"errors" => array(
array("code" => "404", "description" => "Method class not found"),
array("code" => "418", "description" => "I'm a teapot"),
),
"notes" => array(
"You are beautiful",
),
)
)
Valid method details include:
A short blurb describing the method.
A boolean flag indicating whether or not to include this method in the online (and API based) documentation.
A boolean flag indicating whether or not this method can be called.
The name of the library to find the actual function that a method name corresponds to. All things being equal this is what will be invoked.
An optional list of dictionaries containing parameter definitions for the method. Valid keys for each dictionary are:
-
name - the name of the parameter
-
description - a short text describing the requirements and context for the parameter
-
required - a boolean flag indicating whether or not the parameter is required
An optional list of dictionaries containing error definitions for the method. Valid keys for each dictionary are:
-
code - the numeric code for the error response
-
description – a short text describing the reasons or context in which the error was triggered
Error codes are left to the discretion of individual developers.
An optional list of notes that are each blobs of text.
If present then the API dispatching code will ensure that the HTTP method used to invoke the (API) method matches.
A boolean flag indicating whether or not a method requires an authorization token to be passed (and tested).
This is not necessary to declare if you are using OAuth2.
A boolean flag indicating whether or a method requires that a valid (Flamework) crumb ba passed (and validated).
A boolean flag indicating whether or a method requires that access to the method be restricted (or "blessed") by API key, access token or host.
API method "blessings" are discussed in detail below.
The $GLOBALS['cfg']['api_method_definitions'] config variable is a little
piece of syntatic sugar and helper code to keep the growing number of API
methods out of the main config.
This allows to load API methods defined (described above) in separate PHP files whose naming convention is:
FLAMEWORK_INCLUDE_DIR . "/config_api_methods.php";
Where the methods part is used to denote a particular group of method definitions. For example:
$GLOBALS['cfg']['api_method_definitions'] = array(
'methods',
);
See the included config_api_methods.php for an example of this setup.
"Blessed" API methods are those methods with one or more access controls on them. Access controls are always based on API keys and may also be further locked down by API access token, host (the remote address of the client calling the API method) and by Flamework "environment".
API blessings are defined in $GLOBALS['cfg']['api']['blessings'] setting. For
example:
$GLOBALS['cfg']['api']['blessings'] => array(
'xxx-apikey' => array(
'hosts' => array('127.0.0.1'),
# 'tokens' => array(),
# 'environments' => array(),
'methods' => array(
'foo.bar.baz' => array(
'environments' => array('sd-931')
)
),
'method_classes' => array(
'foo.bar' => array(
# see above
)
),
),
);
Each definition is keyed (no pun intended) by an API key whose value is a dictionary containing some or all of the following properties:
A list of dictionaries (or hashes) that define the API methods that this key has been blessed to access.
Each dictionary is keyed by a fully qualified method name whose value is an array that may be empty or contain one or more of the following properties: hosts, tokens, environments (described in detail below).
A list of dictionaries (or hashes) that define a group of API methods that this key has been blessed to access.
Each dictionary is keyed by one or more leading parts of a method name, or a
"class". For example if you wanted to grant access to all the methods in the
foo.bar class of methods (foo.bar.baz, foo.bar.helloworld and so one) to
an API key you would say:
'foo.bar' => array()
The value for each key (class) is an array that may be empty or contain one or more of the following properties: hosts, tokens, environments (described in detail below).
A list of IP addresses (in addition to a specific API key) allowed to access a given API method.
If defined in the scope of an API key these restrictions will apply to all child method and method class definitions. Note if this key is defined as a empty list no requests will be granted access to its corresponding API method.
A list of API access tokens (in addition to a specific API key) allowed to access a given API method.
If defined in the scope of an API key these restrictions will apply to all child method and method class definitions. Note if this key is defined as a empty list no requests will be granted access to its corresponding API method.
A list of Flamework "environment" names (in addition to a specific API key) allowed to access a given API method. Which means this API method will only be accessible on a list of servers that self-identify with this name.
Environment names are defined in the $GLOBALS['cfg']['environment'] setting.
If defined in the scope of an API key these restrictions will apply to all child method and method class definitions. Note if this key is defined as a empty list no requests will be granted access to its corresponding API method.
These are the URLs/endpoints that will be added to your project if you install flamework-api.
Take a look at the .htaccess file and pay close attention to all this stuff that's been commented out at the top. It's a lot of hoop-jumping to separate API calls (api.example.com/rest) from all the other user-level administrative pages (example.com/api/methods) and to make sure things that need to be done over SSL are (like OAuth2).
By default it's all commented out because what do I know about your webserver is configured. So spend a couple minutes looking at all this stuff and thinking about it and adjusting accordingly.
Also: Remember that all the security around OAuth2 is predicated around the use of SSL.
A simple landing page for the API with pointers to documentation about methods and delegated authentication.
The list of public (enabled and documented) methods for the API.
Documentation and examples for individual API methods.
The list of API keys registered by a (logged in) user.
Create a new API key.
Review or update an existing API key.
The list of OAuth2 access tokens associated with a given API key.
A simple landing page for the OAuth2 webpages with pointers descriptions and pointers.
The standard OAuth2 authenticate a user / authorize an application webpage.
A non-standard helper OAuth2 webpage to allow (logged in) users to create themselves both an API key and a corresponding access token from a single page by "clicking a button".
The standard OAuth2 echange a (temporary) grant token for a (more permanent) access token endpoint. This is meant for robots.
A list of OAuth2 access tokens for a (logged in) user.
Review of update an existing OAuth2 access token. (Note how we are passing around the API key in URLs and not the actual access token.)
This is the actual API dispatch/endpoint. Code points here.
-
A good web-based API explorer
-
Admin pages for viewing API keys and tokens