<c:choose> <c:when test="${user.likes}"> Share this with your friends </c:when> <c:otherwise> Send me feedback. </c:otherwise> <:choose>
Now that we know where was the user before we redirected him/her to the authorization prompt, we know the structure of our redirect_uri. After decoding (Base64) the Signed Request then we need to look for an attribute named "user_id", if this attribute is not present then the user has not yet authorized our application to access their information. In the first draft I decided to do an automatic redirection to the authorization prompt but then I thought about it and I chose not allow the user to have control over the flow; never force the user to do things if you don't know whether they want to do them or not.
In this design a simple Facebook logo with a link to the authorization prompt will be displayed to let the user decide to link their profile information to our application or to browse the application as a guest user. In the canvas version the link provides an onclick event handler to set the window.top.location and in the web application version a regular link.
Now, how to know if the user authorized our application after the prompt? The user is going to be redirected to the redirect_uri you provide and the parameters passed to this uri are the key. If you get a "code" parameter then the user authorized the app, if you get an "error_reason" parameter (along with other error parameters) then the user did not authorize it. In the filter I check if the requested URL is the redirect_uri and then I do 2 things, first i look for the "source" parameter I passed along with the redirect_uri to know where to send the user after I retrieve their access token which provides us with a means to know the information they have allowed us to access, second I look for the "code" or "error_reason" parameters and if the "code" parameter is present then we need to exchange it for an access token by fetching a URL (web service) and parsing the (JSON) response. If the "error_reason" is present then we can log the error reason, nothing much after that. The filter redirects the user to the canvas if the "source" parameter is canvas or simply continues to the regular flow if the "source" is site.
That covers, on an eagle-view, the canvas authorization process, now the web app authorization process and at the end of this chapter there will be a detailed design for the filter.
The web app authorization process is now more simple since we made the canvas authorization process practically the same by providing a link to the authorization prompt. The difference comes in the JSP file, if you find a "signed_request" parameter then the user is coming from canvas and we need to use an onclick event to set "window.top.location=<fb_auth_url>" and if it's not present then a regular link to the fb_auth_url.
The rest is the same because we now took the common parts of the authorization and the only thing that changes can be decided by checking the "source" parameter and redirecting to the relevant page accordingly. After we have fetched the access_token (the user authorized our application to access their information) we need to store it for safe-keeping and to avoid going through the whole process each time the user comes to our application. It's is so that now we need to change the first part of our algorithm, we need to check if the access_token is present for the current visitor and if it's not then provide a link to the authorization flow.
That's all there is to it on paper, now on the next section the relevant algorithms to decide in which part of the authorization process currently the user is going through, how to parse the "signed_request" parameter, how to verify the encoded signature and how to fetch the "acccess_token" after the user has authorized us.
No comments:
Post a Comment