3

To my understanding the rate limit for facebook API is about 600 calls per 600 sec, per token & IP. Now I have a website/facebook-app that allows users to browse public nightclub pages and events which does not require the user to be logged in to browse the pages so I use my App token for that. But for the user to be able to use the features on my website/app where their account interacts with the facebook graph, they have to be logged in so I use the user token for that.

So when the user is logged in, there should not be a problem with exceeding the rate limit since each user will have a different user token so each user will have a rate limit of 600 calls per 600 sec. But my concern is that my app will exceed the rate limit when the user is browsing public nightclub pages and events when they are not logged in since there will be only 1 app token and 1 IP adress(my server) being used for mutiple users. If there are mutiple users browsing the public nightclub pages and events at one time then it will be very easy to exceed the rate limit.

I've done some research and found that I can make the API calls from client-side, that way there will be a different IP address(users computer) for each user that is browsing public nightclub pages and events, so then each user will have a rate limit of 600 calls per 600 sec. But then if I make the API calls from client-side, then would my app token and app secret be visible to the user? Would this be a security risk? Can anyone verify if this is correct? Is there any other thing I can do so that the rate limit is not exceeded when users are browsing public nightclub pages and events? Thanks in advance.

Angelo Rodriguez
  • 127
  • 2
  • 14

1 Answers1

1

When making calls from client side you do not provide the app secret, only the App ID, which the client can see regardless, because they are logged into your app. The Facebook cookie for your app contains your App ID. Each client gets their own token, which they can also see.

I'm not sure what "browsing nightclub pages" means technically, but if you can offload server work to the client using JavaScript, that is preferable. Also, when authenticating a user on your server side, try not to call $facebook->getUser() on every page request because that counts against your API limit. Try to log in clients using JavaScript if possible, if not log them in ONCE with FB server-side then set up your own session to authenticate them with your site from then on. This will cut down immensely on your API calls.

See this question: Structure of a facebook app with minimal api calls

Community
  • 1
  • 1
Paul Cristea
  • 453
  • 4
  • 10
  • Thanks for responding, but I'm not sure you fully understood my question. – Angelo Rodriguez Apr 27 '13 at 00:26
  • A "public nightclubs page" is a public page on Facebook that is administered by a nightclub. My website/app displays pages of nightclubs that are located near the user based on that user's location. But the user is not required to be logged in to view these pages because they are public pages, so I use my app access token to make these calls. But since the user is not logged in, there will not be a unique access token for each user, they will all use my app access token when the API calls are made. – Angelo Rodriguez Apr 27 '13 at 00:28
  • So since multiple users will be using 1 access token(my app token) and 1 IP(my server IP) it would be easy to exceed the rate limit if multiple users are browsing pages at the same time. In the following Facebook doc it says not to include app token or app secret in client-side code: https://developers.facebook.com/docs/concepts/login/access-tokens-and-types/ – Angelo Rodriguez Apr 27 '13 at 00:29