Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h3>Time till expire</h3> <p>Short answer: you get the seconds until it expires, but the c# api appears not to expose it.</p> <p>According to <a href="http://developers.facebook.com/docs/authentication/server-side/" rel="nofollow noreferrer">this</a> facebook documentation, you get the the number of seconds until the token expires as a paramater when you get the token. The documentation lists the response format as :</p> <pre><code>access_token=USER_ACESS_TOKEN&amp;expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES </code></pre> <p>This is backed up by the the draft <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.2.2" rel="nofollow noreferrer">RFC</a> for Ouath 2 which says responses should contain the expire time. </p> <p>Unfortunately, it is directly contradicted by the C# SDK documentation that states <a href="http://csharpsdk.org/docs/web/handling-expired-access-tokens" rel="nofollow noreferrer">here</a> that </p> <blockquote> <p>There is no way to determine if an access token is expired without making a request to Facebook. For this reason, you must always assume that an access token could be expired when making requests to Facebook. </p> </blockquote> <p>This is not true. If you look at the c# SDK source, the object the sdk creates for the OAuth response explicitly contains ( unfortunately as a private variable) the following <a href="https://github.com/facebook-csharp-sdk/facebook-csharp-sdk/blob/master/Source/Facebook/FacebookOAuthResult.cs#L40" rel="nofollow noreferrer">code</a></p> <pre><code> /// &lt;summary&gt; /// Date and Time when the access token expires. /// &lt;/summary&gt; private readonly DateTime _expires; </code></pre> <p>So it has the data, but for some reason does not expose it ( at least there, I didn't look to much further). I'd say either dig around the library more and see if its exposed somewhere, fork and patch it on github(i believe it's a one line change), or use reflection to read the private variable in your own code.</p> <h3>Continuing to handle the service method and renew token</h3> <p>Short answer: Maybe. If you knew the token was expired, you could obviosuly get a new one before the request. </p> <p>If you don't, than you kinda can, but you need to handle your request failing. In theory, this doesn't mean you need to handle an exception, just look at the http status code (which will be one in the 400s probably 403 forbidden ) however C#'s <a href="http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse.aspx" rel="nofollow noreferrer">webrequest</a> method interpets non 200 status c as events that raise an exception. Since the API uses this mechanism to make calls, you only get an exception when they fail.</p> <h3>Is there a way for the service method to wait for the new access token we retrieve from the</h3> <p>Sure, after you handle the exception. </p> <p>Once this happens, asynchronously, you will get a new auth token. So you can, after catching the exception, wait some amount of time,check if you get a new token for that user, and if so retry . If keep waiting and checking. Make sure you have a maximum number of retries and a maximum amount of time to wait. Pulling the database to check for changes is a little inefficient, so you probably want to pick the time interval you check for changes on carefully and potentially make it <a href="http://en.wikipedia.org/wiki/Exponential_backoff" rel="nofollow noreferrer">exponentially back off</a>.</p> <p>The other, more efficient (for a single server), but complex way, is to have the system that gets the callback with the auth token raise events and have the retry logic listen for those events.</p> <p>When your code gets an exception because your token is expired, in the catch block make a function that will redo the request and then add it as an event listener to the auth events. Have the function check that the event was for a fresh auth token for the users who request the event and if so, make the request. Again, remember to have a maximum retry count.</p> <p>It is not possible to actually use async/await or something like that to wait for your request for a new token to cmplete. The problem, refreshing the API token is not request that you can wait on the response for , its actually triggering something that eventually causes a seperate get request to be made<br> <img src="https://i.stack.imgur.com/9AR4F.png" alt="Facebook API requests"> Note, although the above diagram is for when a user first logs in, the same sequence happens roughly on a failed call, but it starts with the redirect.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload