In order to make calls against the MOO API, we need to know which application is making the calls for tracking, and security purposes. Previously, the MOO API required 3-legged authentication to make calls as the pack data was held on a user's session, but this requirement no longer exists. You can simply make 2-legged OAuth signed calls (AKA signed fetch). The customer no longer needs to grant access before being able to see your application at work! Once you redirect a customer's browser to one of the drop-in URLs returned by an API call they will take ownership of the Pack, at which point the API user can no longer access it.
Desktop Accessories
//This example assumes you're using the OAuth
//module - http://php.net/oauth
$consumerKey = "<YOUR CONSUMER KEY>";
$consumerSecret = "<YOUR CONSUMER SECRET>";
$oauthClient = new OAuth($consumerKey, $consumerSecret);
//We don't need a 3-legged access token
$oauthClient->setToken("", "");
//Make a pack
$oauthClient->fetch(
"http://www.moo.com/api/service/",
array(
"method" => "moo.pack.createPack",
"product" => "businesscard"
),
OAUTH_HTTP_METHOD_POST
);
$createPackResponse = $oauthClient->getLastResponse();
The MOO API uses the OAuth protocol, but for most calls (and in particular all the moo.pack calls) we only require signed calls, rather than 3-legged calls with user access tokens.
"OAuth allows customers to keep their MOO user name and passwords private and not share them with a partner site."
More formally, OAuth authentication is the process by which "users" grant a "consumer" access to a "service provider" "resource" without disclosing their "service provider" account details to the "consumer". Some definitions may help make this clearer!
Simply put, for a partner web site to use the MOO API they must first obtain permission from a user with a MOO account. The user can decide to authorise or deny permission. See below for how OAuth works for "users" and "consumers".
For calls which require the user to grant access to their MOO account to the calling application, the process by which users grant the consumer permission to access the service providers resources is called authorisation. When a user selects a function on a consumer web site that uses the MOO API, the user will be directed to the MOO web site. If they are not logged in, then they must do so. They are then presented a page with the following message and "Deny" and "Allow" buttons:
Example Application (www.example.com) would like to have access to your MOO account. You can choose to Deny or Allow this access.
By selecting "Allow", the user grants permission to the consumer to access the service providers resources, which basically means that the partner site can now use the MOO API to make calls against the user's account. At this point, there are no calls which require 3-legged authentication.
Consumers must first register for credentials. See registration. Once registered, the consumer must use the OAuth authentication protocol flow to obtain authorisation from the user and receive an access token. Only API method calls signed with this access token are permitted.
Direct access or 'Two-legged' OAuth dispenses with the need for request and access tokens by directly verifying the signature of requests based on the consumer credentials of 'Consumer Key' and 'Consumer Secret'. This is the model that almost all MOO API calls should follow as they don't need access to a user's account. Here, the consumer and user are the same entity. Unlike delegated authorisation or 'Three-legged OAuth', users do not authorise access on an individual basis.
Delegated authorisation or 'Three-legged' OAuth is the protocol where the three parties of user, consumer and service provider are involved. The work-flow is described below. An excellent guide to the OAuth protocol can be found here.
We offer super-fast printing and shipping options if you need your order asap!
MOO Business Services offers easy ordering for companies with 10+ employees
We’re only happy when you’re happy – our customer service team are always there to help
