A mobile-based application communicates directly with Fire Eagle without going through a web server that modifies the requests. For each user that wants to authorize your app, the following illustrates the authorization flow.
|
Obtaining an unauthorized request token
Request Token URL
https://fireeagle.yahooapis.com/oauth/request_token
Required Parameters:
oauth_consumer_key : application consumer key
oauth_callback : set this to a value of 'oob'
oauth_nonce, oauth_timestamp, oauth_signature_method, oauth_version, oauth_signature
Same as for web applications, your application first makes an API call to Fire Eagle for a request token. Fire Eagle will respond with a unique request token. This request token is temporary for this user authorization session. For mobile applications, the request token will be suitable for manual user entry and is valid for only 1 hour after being issued. Note that unlike web applications, you cannot pass an actual callback using the oauth_callback parameter.
|
|
Obtaining user authorizations
User Authorization URL
https://fireeagle.yahoo.net/oauth/mobile_auth/<APP_ID>
Required Parameters:
This step differs the most from web application authorizations. After obtaining the request token, your application displays the request token (just the token part, not the oauth_token_secret) to the user. Your application then instructs the user to manually go to the Fire Eagle authorization URL for your application. This Mobile Authorization URL includes an application ID for your application -- you can see the URL on your Manage Applications page.
When the user goes to the Mobile Authorization URL, he is shown a form where he can enter the request token displayed in your application and choose the permission levels to grant to your application.
After the user confirms authorization of your application, he is done with Fire Eagle web site, as far as authorizing your app goes. However, because there is no callback URL for mobile applications, Fire Eagle will display instructions to the user to follow the next steps on your application. In particular, it will display a 6-character verification code that your application should require the user to key in.
If the request token has expired because the user did not visit the Fire Eagle site within the hour, Fire Eagle will instruct the user to go back to your application to get another request token. Your application should be able to obtain another request token from Fire Eagle and display that to the user.
|
|
Obtaining user-specific access token
Access Token URL
https://fireeagle.yahooapis.com/oauth/access_token
Required Parameters:
oauth_consumer_key : application consumer key
oauth_verifier : verification code keyed in by user in step 2.
oauth_token : the request_token that you obtained in step one.
oauth_nonce, oauth_timestamp, oauth_signature_method, oauth_version, oauth_signature
Similar to web applications, after the user authorizes your application, your application needs to exchange the request token for a permanent user-specific access token, access token for short. Regardless of the application type, the access token uniquely identifies the user to your application, represents the permissions the user has authorized to your application and allows your application to update or query Fire Eagle for the user's location information on behalf of the user.
To get the access token, your application needs to accept the verification key. At this point, your application needs to make an API call to Fire Eagle with the request token and the verification code for the access token. If the user has properly authorized your application, Fire Eagle will respond with a unique access token for the user.
|
|
Managing and storing the access token
You will receive an access token and access secret for the user which you need to store together securely. The access token ties the user to your application and is your pass to update and query for the the user's location within Fire Eagle. You need to figure out how your application associates the access token with your application's representation of the user. The access secret is used to sign your application's query and update requests for the user.
For mobile-based applications where the user has his own phone, the access token and access secret is intended to be distributed to that user's mobile device. You should store these credentials as safely as possible on the use's device (e.g. encrypted in a secure device data store) as the user's location information may be exposed if the user's access token and access secret are compromised.
|
|
Documentation
QUICK STARTS
AUTH & OAUTH
QUERYING & UPDATING
PDF DOWNLOADS
API KITS & EXAMPLES
YOUR RESPONSIBILITIES
|