Using the SDK with the cloud requires an API Key and Secret that are known to both AccountRight and your application, please ensure you have completed the getting started process so you have these ready to go at your disposal.
In addition to the APIConfiguration class implemented with the local desktop service example, the SDK requires an IOAuthKeyService to deal with the cloud. As touched on with our SDK key structure pillars, the SDK provides an implementation of a SimpleOAuthKeyService for managing OAuth tokens but this won’t store these between sessions.
This code snippet shows setting the developer key, secret and necessary services required for online access:
var developerKey = "YOUR API KEY";
var developerSecret = "YOUR API SECRET";
var configuration = new ApiConfiguration(developerKey, developerSecret, "http://desktop");
var oauthService = new OAuthService(configuration);
var tokens = oauthService.GetTokens(OAuthLogin.GetAuthorizationCode(configuration));
var keystore = new SimpleOAuthKeyService();
keystore.OAuthResponse = tokens;
// Get Company Files
var cfService = new CompanyFileService(configuration, null, keystore);
var companyFiles = cfService.GetRange();
The function OAuthLogin.GetAuthorizationCode is a helper class created in the samples that illustrates how to create a form that launches the secure.myob.com my.MYOB login page.
A user is required to enter their my.MYOB credentials from here and sign in, upon signing in a prompt is displayed asking the user to authorise access to your app the very first time OAuth is run.
Once completed, the desktop redirect uri is used to retrieve the access code in the content of the HTML to extract for the purpose of exchanging it for an access token.
Our samples also incorporate an OAuthKeyService class that is used as an example of how to save tokens between sessions using Windows Isolated Storage. This means an end user only needs to login and complete the OAuth process once (Screenshot of tokens in Isolated Storage).
The SDK then uses the provided IOAuthKeyService to manage all subsequent interactions with the OAuth service such as refreshing the token on expiry. This is ideal for a single user integration but if multiple logins are common then it would need to be adapted to facilitate as needed.
As this is purely an example, a developer can create their own class or simply adapt the existing OAuthKeyService to store tokens in a secure database or another storage method as required.
Once again just like the desktop service, calling other API services requires the supplying of company file sign on credentials with the CompanyFileCredentials class.
Article is closed for comments.