Does LinkUserFacebookAccount() create a user?

+1 vote
It is not clear, does LinkUserFacebookAccount() createa a user account in App42, ready to have things like profile data, roles, etc, assigned to it?  Or do you have to call CreateUser() first to create the user, and then link it to Facebook using LinkUserFacebookAccount()?

Since I am doing my authorization through Facebook, I'm unclear as to what App42 calls I still need to make to ensure the user accounts created are fully functional.

asked Jul 17, 2014 in App42PaaS & BPaaS by Brady Wright (35 points)

1 Answer

0 votes
Best answer
Hi Brady,
If your user base is with facebook, it is not recommended to use App42 User Service in that case because your user auth and profile is managed by facebook.  If you want to save additional profile info of fb user, you can use Storage Service (See this) and dump all these information right there in JSON object. You can use fbid of user as one of the key in the JSON object to tag user data. These information can be fetched back by applying query on it.
Let me know if it makes sense.
answered Jul 18, 2014 by ajay123 (899 points)
selected Jul 22, 2014 by Brady Wright
Okay, but then what does LinkUserFacebookAccount() do?  Can this be explained in more technical detail?  Also, if I just use the Storage Service and not the user service, what about if I need to use ACL and restrict the end-user's access to only JSON documents they "own"?  Don't I need App42 user accounts for that?
LinkUserFacebookAccount just stores user accesstoken against username(fbid) so that UpdateFacebookStatus, GetFriendFromFacebook methods in social service does not require to pass access token and can be called just passing username.(In Non ACL case). For ACL app you actually dont have to call this LinkUserFacebookAccount method. ACl services in App42 works using App42 Service or Facebook user account. In case of App42 User, you have to pass sessionId in every request however for facebook user you have to pass facebook access token. (See this
So does that mean, for example, if I want to call StorageService.GrantAccessOnDoc(), I need to send it a hash set with an ACL like so?:

new ACL("<user's Facebook ID>", Permission.READ)

...instead of the user's App42 user name?  But if I don't call LinkUserFacebookAccount(), how does App42 track user permissions?

Alternatively, if I want to use App42's User service, couldn't I just use the Facebook native API, and after authentication, use the Facebook user ID as the App42 user name, and the Facebook access token as the App42 password, and then do a second authentication step using App42's UserService?  Do you see any reasons, aside from redundancy, that I should not do that?

Yes, in case of facebook you have to user username as facebook user id and instead of serssionId you have to pass access token, rest will remain same. Calling LinkUserFacebookAccount is optional in this case, because if user is not linked, App42 internally does it automatically on server side during the method call using username (fb id) and accesstoken (required to be passed in every request). If accesstoken and fb userid not valid and does not belongs to claimed fbid, App42 will throw the exception in that case.

You can use App42 User Service, however redundancy and password management is the key thing that needs to be taken care. You can use access token as password, however you have to reset it every time when access token expires. Managing random generated password can not be used as you have to save it securely somewhere and managing it again an additional task. You can also opt to create password using your own algo however you have to make sure that it is secured enough and probability of cracking this algo is pretty low.
Okay, just to clarify, when you say the access token is required to be passed in every request, do you also mean requests like InsertJSONDocument(), UpdateDocumentByDocId(), FindDocumentsByQuery(), etc?  Because I don't see any parameters to those methods that would accept an access token, unless you mean to precede every single API call with a call to SetFBAccessToken().  But I assumed that only needed to be called once at the beginning, and then you could make all the API calls you needed to after that.  Can you please clarify?

Setting fb access token on app level is not there in the SDK currently. This issue is already logged and we will push this in our SDK in coming release. Currently you have to pass fb accesstoken by calling SetFBAccessToken method on service reference. You can make your service reference as static and set this at once user is authenticated. Let me know if it makes sense.
I see, so to make sure I understand: I must call SetFBAccessToken() on every service I instantiate, and then I can make as many calls to that service as I need after that and do not have to call SetFBAcessToken again until I instantiate another service?
That is correct.
Hi there,

another doubt regarding this question.

My app is a Facebook app. Our players can play on single player or multiplayer mode.

When they login I’m using SocialService.linkUserFacebookAccount function to link these users.

The problem is that from my dashboard, I can see these users browsing:

Business Service Manager >> Social Service >> Facebook..

But I can’t see these users under User Service >> User so I can’t send them push notifications, a key functionality we want to use in the future.

Can you please explain how can I create these users on both social service and User Service or how can I use Push Notifications with Facebook Users?

Kind regards and many thanks for your help.
To use Push Notification, you dont need to create user with App42. You have to just use Push Notification service and register his device using username. In your case userName would be fbId of user. Once user device is registered you should be able to see under Push Notification > User tab.
 Please see here our tutorial for Push Notification here
Download Widgets
Welcome to ShepHertz Product line forum, where you can ask questions and receive answers from the community. You can also reach out to us on