Facebook SDK for Unity, server-side code and cookies

I posted this on the forum but got no response over the weekend so I thought I’d post it here. Might be a better place for it anyway.

I’ve been trying to update our current Unity project to use the new Facebook SDK for Unity and all the lovely features that come with. Up until now all we’ve had is a server-side implementation to request permissions using the PHP SDK. We held off on further implementation as we knew the new SDK was going to be released imminently.

However, now that we’re implementing it, we’ve run into a slight problem getting it to fit with our current process. Now that Facebook Apps can link directly to a deployed .unity3d file, the PHP page that the web player used to sit in no longer gets hit and as a result, none of the PHP code is executed. We used the server-side code and PHP SDK to do the account creation for new users but because this is no longer being hit, new accounts are no longer created.

In the settings for the Facebook SDK for Unity asset, it actually has a tick box for “Cookie” with a description that implies usage in server-side code… but I have no idea how I’m supposed to access this cookie when the web page specified as the Facebook App’s (Secure) Canvas URL is never hit… not even once.

15715-fbsdkscreenie.png

I’ve searched around and can’t find anyone else with a similar problem, so either I’m doing something wrong or it’s not been encountered? Hopefully it’s something simple and I’m just being daft

Anyone know how to solve this?

Thanks!

Hi @Jargon, you’re correct that the new SDK won’t hit your servers explicitly any longer as only the static file is fetched by the canvas page. I can’t tell you what the best approach would be, but you have two approaches:

  1. Implementing your account creation flow in C# and using the WWW class to post to your servers (i.e. an RPC flow)
  2. using native calling to pop up an iframe or popup for account creation
  3. redirecting to a webpage that serves your login flow (basically the same as 2, but maybe simpler)
  4. continue to serve your game as you are currently, but use the Unity SDK. You can still compile the your game with the SDK and get the benefits from it, the one thing you miss out on is native in-unity dialogs.

I’d suggest 1 if you want to bring your game to mobile at some point. Or 4.

Thanks for trying out the SDK!

Aaron