I'm building a Facebook app for a client who have a Facebook company page and I'm stumped as to how to develop the app so that they can actually have access to it without binding it with my own personal FB Login (to which I obviously have no desire to grant them access).
They have added me as an admin to their FB page but when I'm logged into that and go to developer.facebook.com I'm told that to proceed I have to switch back to my own personal account.
I'm sure I'm missing something fundamental here, but am totally confused as to what the process is to build an app for a third party, so that they don't have to give me their personal FB login and I don't have to give them my own.
TIA.
You should create and manage Facebook apps using your real, personal accounts.
You can add multiple, real users to be administrators of an app, and you can add them under several different "roles". You should never give another person the username and password to login to your personal Facebook account.
You should not setup a new Facebook user in order to manage apps. When Facebook's automated systems detect a non-real user account, and that account is suspended, all apps that account is connected with will also be affected.
If you want an easy way to control many users having access to many apps, you can create a secret Facebook group - add all the users who you want to admin the app to the group, then in the Facebook app dashboard, you can add that group to one of the app's role groups. This method has the advantage that, if someone joins or leaves the company, you just have to add/remove them from this group, and they'll then be able to edit (or not) all the apps to which that group has been added.
In short - always use your real accounts - there are ways to make it work for people like you building apps for clients.
You will want to use the Roles settings of the FB app to add Admins (and optionally Developers, Testers, and Insight Users). Each app can have multiple admins. When you create the app you'll be an admin, of course. Then, go to the Roles tab in your app's settings and add others as admins (note, you must be FB friends with them). The people you have added must then visit the Developers site, accept the admin request (under Apps), and will then have admin privileges.
Another way is create a FB group whose members are admins of the app. This is done the same way, but instead of typing a person's name, click "Create a group for administrators" in the "Add Administrators" dialog. Then, add people to the group.
In fact, any of your existing FB groups can be added as an admin, developer, tester, or insight user of the app.
Yet another option is to have the client create the FB app initially (ie. just the minimum config), and then add you as an admin.
More on Roles:
https://developers.facebook.com/docs/ApplicationSecurity/
Related
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
Planning on creating a Google Assistant Application that allows our customers to access business data. The problem I am having is understanding how a given user would link his account to his "instance" of our multi-tenant solution. I think the deeper problem is know which Tenant URL to associate with a particular account. I know I can implement the Accounting linking using Oauth, I have just yet to see how this could work with a single Assistant App accessing multiple tenants depending upon account.
You can get additional info from the user, by asking him, and save that in your context, and then you can request for a sign in. this way, during the sign in process, you can use the context to sign in the user into the proper tenant
I've updated my app to use the new Box V2 API instead of the old Box V1 API.
I have only one question left : After revoking access to an app ( http://developers.box.com/wp-content/uploads/2013/08/Provision-Reject.png ), why is it required to grant access again after giving the password again?
Thanks for your answer in advance!
When a user decides to revoke access to an application, they've basically decided that they don't trust that application to get to their Box content. If they change their mind and want the application again, then the user should know what kinds on things your application can do.
The "grant access" screen is part of the OAuth2 specification, and is used by just about every website these days that lets applications get at user's accounts. Android apps have a similar "grant" screen to say stuff like "This application wants to get at your address book, send emails, and ... only use it if you trust the application to do these things."
I am thinking of tying in a Facebook JavaScript-based application with an existing website that has it's own user accounts, but have a question about a specific user situation.
The website is run almost 100% of the time from 'shared' computers, like those found in a career center. User A comes to my website, signs into the site and then authorizes the Facebook app, which stores their session in the browser, along with, effectively, signing them into Facebook.com.
User A now leaves my application by signing out of my site - but not closing the browser.
User B arrives, logs into my site with their login, but the Facebook session is still active (due to the browser staying open), so any FB app integrations I've included will show as if it is still user A, correct?
So the question is, what are the recommended ways to deal with this? Two options come to mind:
When the user signs out of my website, I fire an FB.logout call, so that all of the sessions are killed. Pros - I can ensure that user's signing into the site will not have old sessions hanging around. Cons - a user who is returning shortly after leaving will have to re-login to FB as well as my site to see the FB integrations - I'd love to avoid the user ALWAYS having to do two logins. Secondly, forcing the FB.logout when they leave my site kills any active sessions they have at facebook.com, which makes for a bad user experience as they would not 'get' why logging out of my site has anything to do with facebook.com, and will then have to re-signin to facebook.com.
The second option would be that when the user authorizes the FB app, I take their member ID and store that locally and persistently (database). Then, when a user returns to the site and signs in, I check their FB auth status, and if logged in to FB, pull their member ID and check it against the one I have stored locally. If they match, I have the correct user, if not, I do FB.logout and have them sign in to FB. Pros - this should ensure I always have the correct user to the site. Cons - not sure if getting, storing the member ID is feasible.
Any suggestions or pointers to the 'best practice' when it comes to ensuring that the current user is indeed the one associated with the FB account, specifically in this 'shared computing' situation where sessions may overlap?
Thanks
The second option looks to me to be the better choice. You can indeed store the users facebook id. By storing it locally i'm assuming you are talking using a cookie; however storing in a database is just as feasible.
Facebook user id's should be stored with a BIGINT(20) data type - such are the recommendations from facebook.
Taken from the user section of the facebook api refrence :
Looks like they changed their recomendations...
I'm a person with a non-programming background working on a web application that must store user-generated content and always associate that content with the user who created it. I just had the developer tell me since the application must do this, using Facebook as an alternate login method is pointless because Facebook only let's a third-party web application hang on to Facebook profile information for a certain amount of time, and therefore users who login via Facebook cannot actually contribute content that would remain in the web application's databases.
I'm having trouble swallowing this. I just signed up and logged in to stackoverflow using my Facebook account, and it appears to have generated a site-specific user ID that was automatically associated with my Facebook account - thereby allowing me to save/store content on the site without having to actually create a site-specific profile.
My questions:
Where is the misunderstanding here? To what extent do alternative login options affect the ability of my application, which will consist largely of user-generated content, to store user-generated data and consistently associate it with that user? Appreciate the help!
Alternative login allows users to use an existing account to sign in to multiple websites, without needing to create new passwords. Alternate login using facebook, OpenID, gmail or any other provider doesn't affect the ability of your application to store user generated content.
When a user logs in using a login option for e.g. facebook, user enters the facebook login credential(if he isn't already logged in), facebook generates a authenticated token which is utilised by your application for future use.
In case of alternative logins only the login information (User ID/Password) isn't stored in your application, it totally depends on how you are implementing it in your application. But in any case it doesn't affect your application in saving storing and using the user generated content in your website.
Please refer to this link for more info -
http://openid.net/get-an-openid/what-is-openid/
http://oauth.net/
Hope this helps!