This is an issue derives from the following discussion:
https://aspnetwebstack.codeplex.com/discussions/527849#post1199675
Scenario: when user cancel the permission request dialog, facebook app will redirect to the same page cause another request dialog triggered eventually build a infinite loop.
Investigation: There is a mechanism in our Facebook authorization filter to decide whether we will redirect to :
1. App’s front page therefore to request permission if required ones are not granted, or
2. A designated authorization error page to notify user the permission is missing, in which case no further permission request will send.
The situation user runs into is that the route 1 is always triggered. The reason why we do that is because we’re expecting an “error” parameter in the call back from facebook OAuth dialog when user cancel a permission request. However, we observe that Facebook doesn’t add “error” parameter. As a result an infinite loop is constructed. The behavior is different from what is stated in the Facebook’s document (https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow).
We can't simply remove the "hasError" condition, because we need to distinguish the scenario of the first time login and later login.
So questions:
1) Why does Facebook not send the right query string?
2) How can we solve the situation properly.
Comments: [Detail Facebbok knowledge regarding to the investigation are majorly documented here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/] Root cause of this bug is an unexpected Facebook authentication behavior. We redirect user to following url for authentication: https://www.facebook.com/dialog/oauth?redirect_uri=<https://app_home>%2F&client_id=<clientid>&scope=<permissions> Base on Facebook documentation, when user cancel/skip the permission we expect user agent will redirect to the given redirect_uri and present error_reason parameter in query string. However Facebbook doesn't add the parameter, instead it appends "code" parameter as it treats the login is successful (even though user reject it) The redirect_uri will therefore trigger authorization filter again and cause loop. The key step is to break the loop. One solution is to append a "state" parameter to the oauth dialog url. State parameter and value will be pass on to query string when user agent is redirected. Using this parameter we can pass on information regarding if it is the first time permission requesting or second time. For second time, app can stop retrying and direct to error page directly. The other solution is to allow user re-write their own condition or retry. Open up the authorization filter for override so as to prevent the template from being broken by future Facebook API change.
https://aspnetwebstack.codeplex.com/discussions/527849#post1199675
Scenario: when user cancel the permission request dialog, facebook app will redirect to the same page cause another request dialog triggered eventually build a infinite loop.
Investigation: There is a mechanism in our Facebook authorization filter to decide whether we will redirect to :
1. App’s front page therefore to request permission if required ones are not granted, or
2. A designated authorization error page to notify user the permission is missing, in which case no further permission request will send.
The situation user runs into is that the route 1 is always triggered. The reason why we do that is because we’re expecting an “error” parameter in the call back from facebook OAuth dialog when user cancel a permission request. However, we observe that Facebook doesn’t add “error” parameter. As a result an infinite loop is constructed. The behavior is different from what is stated in the Facebook’s document (https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow).
We can't simply remove the "hasError" condition, because we need to distinguish the scenario of the first time login and later login.
So questions:
1) Why does Facebook not send the right query string?
2) How can we solve the situation properly.
Comments: [Detail Facebbok knowledge regarding to the investigation are majorly documented here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/] Root cause of this bug is an unexpected Facebook authentication behavior. We redirect user to following url for authentication: https://www.facebook.com/dialog/oauth?redirect_uri=<https://app_home>%2F&client_id=<clientid>&scope=<permissions> Base on Facebook documentation, when user cancel/skip the permission we expect user agent will redirect to the given redirect_uri and present error_reason parameter in query string. However Facebbook doesn't add the parameter, instead it appends "code" parameter as it treats the login is successful (even though user reject it) The redirect_uri will therefore trigger authorization filter again and cause loop. The key step is to break the loop. One solution is to append a "state" parameter to the oauth dialog url. State parameter and value will be pass on to query string when user agent is redirected. Using this parameter we can pass on information regarding if it is the first time permission requesting or second time. For second time, app can stop retrying and direct to error page directly. The other solution is to allow user re-write their own condition or retry. Open up the authorization filter for override so as to prevent the template from being broken by future Facebook API change.