<c:choose> <c:when test="${user.likes}"> Share this with your friends </c:when> <c:otherwise> Send me feedback. </c:otherwise> <:choose>
The algorithms to make the authorization flow described in the previous 2 parts of this chapter are simple and they provide for tweaking and the usual stakeholder requisite changes.
First the core of our filter, how to know in which part of the authorization flow through which the user is in transit:
- Returning authorized user(1)
- Everyone else(2)
- After authorization prompt(2.1)
- Authorized(2.1.1)
- Canvas(2.1.1.1)
- Site(2.1.1.2)
- Not Authorized(2.1.2)
- Canvas(2.1.2.1)
- Site(2.1.2.2)
- Canvas(2.2)
- UserId(2.2.1)
- ProfileId(2.2.1.1)
- No profileId(2.2.1.2)
- No UserId(2.2.2)
- Site(2.3)
Now let me explain how to know and what parameters to check to know in which part of that tree the user is located and what you might do after that:
(1)access_token present in session
Retrieve user information using access_token
(2)access_token not present in session
(2.1)requestURL == redirect_uri
(2.1.1)code parameter present
Retrieve "access_token" using "code"
Store "access_token" in session
(2.1.1.1)source parameter == canvas
Redirect to canvas
(2.1.1.2)source parameter == site
Continue to site
(2.1.2)error_reason parameter present
log error reson
(2.1.2.1)source parameter == canvas
Redirect to canvas with onclick auth link
(2.1.2.2)source parameter == site
Continue to site with regular auth link
(2.2)signed_request parameter present
Decode signed request
(2.2.1)userId present in signed_request
Retrieve user information using access_token
(2.2.1.1)profileId present in signed_request
Retrieve user information using access_token
(2.2.1.2)profileId not present in signed_request
Retrieve user information using access_token
(2.2.2)userId not present in signed_request
Redirect to canvas with onclick auth link
(2.3)signed_request parameter not present
Continue to site with regular auth link
To decode the signed_request you need to use a Base64 decoder which handles URLsafe decoding. After decoding use class javax.crypto.Mac to get a Message Authentication Code for the algorithm passed in the JSON decoded signed_request. Use your aplication secret (known only to you as a developer) and sign the JSON payload of the signed request and compare it to the decoded signature. If they match then you can rest assured the signed_request comes from the Facebook servers.
A few things to keep in mind which will be important when you test your code: use the EXACT same redirect_uri (including the source parameter) to retrieve the access_token. This was clearly stated in the documentation even from the early stages of the migration to the new Graph API, it helped me a lot to remember it. I used all the parameters used by Facebook (appId, appSecret, appKey, redirectUri, canvasUrl, siteUrl) as init parameters of the filter to be able to reuse the filter for other applications without changing code, and just changing those init parameters in the xml configuration.
I would appreciate if you could Share this with your friends
