How do I get access to my client ID and auth? Original developers moved on - facebook

OK, here is my situation. We had two developers create a Social Networking program for us. They created a feature that allows it to link to your Facebook account. They said they used a the standard Facebook API and that it uses a token for authorization. The feature worked great when the code was on our dev site, dev.maizing.com, but now that it is on www.maizing.com we are having a problem.
I searched and found one PHP file that had several references to dev.maizing.com and I changed them to www.maizing.com In our app now when I try to link to my Facebook account, I get a long error url. I noticed it includes ....
https://www.facebook.com/dialog/oauth?client_id=____________
I won't include the whole client_id here.
What I was told is that my original client ID was hardcoded to work with dev and not www. My original developers are gone and are unreachable. I think they have the client_id under another account and I don't have access to it. Have can I get the access to now make our
client_id point to the right server?

Your AppID shown on your app dashboard page is the client_id.

Sounds like you need access to the apps settings, found here:
https://developers.facebook.com/apps/[client_id]/summary/
As this page says, "The URL you specify must be a URL with the same base domain specified in your app's settings..."
So unless you get access to your app settings, you have to stay with "dev.maizing.com"
Sorry.
There is a silver lining though, if you change your app domain to "maizing.com" instead of "dev.maizing.com" then you can us this app from "*.maizing.com" as stated on the tool tip for app domain.

Related

Example of an OAuth Homepage for Google

I have created a flutter application in both iOS and Android that uses OAuth2. In order to authenticate the the app. While I can sign in successfully on iOS, Android provides error the following error:
E/flutter ( 6309): [ERROR:flutter/lib/ui/ui_dart_state.cc(157)] Unhandled Exception: PlatformException(sign_in_failed, com.google.android.gms.common.api.ApiException: 10: , null)
This is almost certainly because of a configuration issue in my OAuth verification request. Their rejection (see below) describes a homepage they require:
Dear Developer,
Thank you for submitting an OAuth App Verification request.
Unfortunately, we cannot proceed further with the verification process
until the requested things are provided.
As we discussed in our previous communication, to proceed with the
verification process for your project what-happend-here you will need
to provide a homepage that accurately represents your app’s identity
to Google users.
Every OAuth2 project requires a homepage. To ensure users’
understanding of your app’s purpose, your homepage should:
Be a verified domain under your ownership
Be accurate, inclusive, and easily accessible to all users
Link to an externally accessible domain that describes the necessary content, context, or connection to the app you are submitting
Explain with transparency the purpose for which your application requests user data
etc.
However, despite the description, I've no feel of what it should be like. Is there an example of such a page that I can use as a model?
Thanks for any help.
I've been back and forth with google over this issue. I can't give a simple answer, but I can summarize the items I've changed in order to meet compliance.
For context, I'm just using oauth on my personal webpage to identify users. I'm not selling an app. I'm not using restricted scopes. I'm not touching any user data.
This should be the simplest case, yet it was difficult to get approval. Each rejection reply is in the style of a form letter. I conclude that an AI has be trained against a set of compliant pages, and it "feels" mine isn't compliant, i.e. it's not able to point to a specific violation like a human or a rule's based system would. For this reason, I advise against spending time in your email replies. It doesn't seem that anyone reads them, just change your content and reply to get the AI to look again.
In the google console you must provide:
a homepage url
a privacy policy url
an uploaded icon image file
If you're using oauth for a website, don't confuse the oauth console "homepage url" with the base url of your website. Google wants a "homepage" that says "what your app is".
The content served at the homepage must have a [link rel="shortcut icon"] whose href points to the identical bytes of the icon you uploaded in the oauth console. If the bytes differ because you're using a scaled or differently styled image, you'll be rejected.
The content served at the homepage must have a privacy policy link where the href is identical to the characters entered at the console. If they're the same page, but differ by an anchor for example, you'll be rejected.
Also watch for caching. I changed the contents of my [link rel="shortcut icon"/] and got a reply that seemed to accept the icon but complain about another issue. Then when I fixed the other issue they rejected me for the icon again. I think since I changed the uploaded icon but didn't change it's name that they later saw a cached icon. I changed just the url (thus invalidating their cache) and the next reply didn't complain about the icon.
If you're not using restricted scopes you shouldn't need the limited use disclosure, but I got a complaint about that so I added it.
Here's what I'm using for both the homepage and the privacy policy:
https://holtstrom.com/michael/about/
Here's how that looked at the time of this posting when it was finally approved.
You'll see that I have all of the google requirements rendered in underline followed by the text that satisfies the requirement.
In case it helps, here's the replies I received from Google:
Google OAuth Consent Screen Verification:
#Michael Holtstrom's answer works perfectly, And I got my app approved in just the 2nd attempt.
But, since there is no information available anywhere on internet regarding this, that's why
I am posting my answer with all the screenshots, only to support #Michael Holtstrom's answer, so that you can move ahead with more confidence.
Because, I was really worried for 3-4 days whether my app will get approved or not. Because this was the last part left in my project.
I was also using Google OAuth only to get email, name and profile picture.
My app could have got approved in the first attempt only, but the first time I submited homepage had text selection disabled(Because I built it using Flutter Web, on which text selection is disbaled by default).
So, I think the Google's AI was unable to read the text on homepage, and thus asked me to update the homepage.
Next time, I built using wordpress, and then my app got approved.
(And by the way, I'm using chrome extension dark reader, that's why all the screenshot has dark mode enabled.)
Youtube Video Url:
https://youtu.be/lzq9WjCXT6c
Consent screen form on GCP Console
Google OAuth Homepage
https://www.madhavkumar.in/about/
Privacy Policy
https://www.madhavkumar.in/privacy-policy/
Email thread with Google Trust Team

How should I deal with the Facebook app privacy policy URL in developers page?

I'm trying to import fb-login function and there are some features which need to be inspected by facebook such as job status, education, etc.
And they're saying that they requires privacy policy URL. So, I made a facebook page, which I will use as a landing page for my app, and wrote down the Privacy Policy to the Note.
After that, I copied the note's url and pasted it to the Privacy Policy URL box. I tried to save and proceed, but than error message comes up,
Facebook URL: Facebook URL cannot be crawled
So, my question is this: Is it unavailable to use facebook page to submit the privacy policy URL? This is my first time importing fb-login, so I just don't know what should I do and what shouldn't I do.
This should work ( Kind of a trick to fool FB ;) )
Create a free privacy policy here.
Upload your privacy policy (the one you just created) to your google drive account.
Select the uploaded privacy policy file and click on Get Shareable link. Copy and paste the generated link into your facebook app's Privacy Policy URL input box and click on save changes.
Thanks ☺️
This is likely the problem.
After that, I copied the note's url and pasted it to the Privacy
Policy URL box. I tried to save and proceed, but than error message
comes up, 'Facebook URL: Facebook URL cannot be crawled'
Instead of using a Facebook note, you're likely required to host that privacy policy yourself publicly. Given that Facebook can be a silo and hide pages whenever they like from the public web, you'd be well advised to move it to a site of yours.
This also seems to be Facebook's requirement:
Provide a publicly available and easily accessible privacy policy that
explains what data you are collecting and how you will use that data.
You may use Account Information in accordance with your privacy policy
and other Facebook policies. All other data may only be used outside
your app after you have obtained explicit user consent.
Include your privacy policy URL in the App Dashboard.
Link to your privacy policy in any app marketplace that allows you to.
Comply with your privacy policy.
How can you do that?
There are a few options:
host on your own site
host on sites that allow to create public and persistent pages (just a thought, github?)
use a dedicated tool for privacy policy creation and hosting like iubenda
Hope this helps (p.s. I work for iubenda)
Facebook has provided a link to test your URL which will show you that your URL is as per their standard or not.
Test your URL here:
https://developers.facebook.com/tools/debug/sharing/
Working
go to this link https://developers.facebook.com/apps
then click Basic tab setting
scroll down till you see +add platform tab and click it
remove all allowed platform link android web....NB makes sure you have the details saved somewhere else ..like on notepad
then go to top and switch the mode from off to live.
your app will be live
then go down again to add platform and add your plaform like android or web
The URL to your Privacy Policy must be public and accessible. That's both a requirement from Facebook and law (see California Business Code and CalOPPA in the US). Here's Facebook Developer Policy:
If you received the Facebook URL: Facebook URL cannot be crawled try to also not block bots access to the Privacy Policy page, i.e. Facebook Link Preview could crawl it or Google bot.
Some of the previous suggestions are not for free as for now. One of the free options I found:
https://www.iubenda.com/en/start-generating
Be sure to select Facebook app, NOT Mobile app, and click "Start Generating"
For those looking for a free solution, I used https://www.termsfeed.com/privacy-policy-generator/ and it was validated in the Meta API in less than 2 minutes.
This site will offer a paid professional solution, but the free one worked like a charm.
Don't worry about hosting. the site gives you a hosted url
Go to Dashboard, Click on the Application
Go to Settings --> Basic at Sidebar
Remove apps if there is any under Add platform
Add policy URL and Turn the status to LIVE
and then you can add apps of your choice for live apps

Facebook connect service for my customers without appid

I have more than few clients that would like to add facebook connect to their landing pages (managed by me). They are too many and not enough tech-savvy to manually create ad appid for each of them.
So my only solution is to usa my own appid to add facebook connect to all my clients websites, but as far as I know, Facebook doesn't allow to simply use the same appid on any domain.
How can I solve this? I can't find any documentation to solve my issue. Does anyone have a direction for me?
This has been discussed a couple o’ times before already – but I mostly commented on earlier questions, so let me write the whole thing up as a proper answer, for future reference.
[paraphrased] Multiple-client Facebook login via one single app id
Does anyone have a direction for me?
You probably rather don’t want to do that.
It is not really possible to run one simple app one multiple different domains.
As a workaround for only a few domains, people used to specify different domains for the different platforms – Website, Page Tab or Canvas App, plus Mobile alternative for Canvas – without actually using any of those platforms besides Website, which made the app usable on multiple domains as a website app. But since Facebook introduced their login/permission review process¹, you can’t do that any more – they expect you to present actual functionality on all platforms you have configured in your app.
You can kind-off use one single app for login on multiple domains – if you are willing to use only the server-side login flow, and to redirect users to one “main” domain (that gets specified as the app domain in the app settings) to login, and then from there back to the origin domain.
But this has several drawbacks:
It’s not what you’d call a “white label” solution. If your clients expect it to look as if users where logging in via “their” app, it should stay on their domain. Individual branding, in regard to stuff such as app name, app logo that shows in the login dialog, etc., would also not be possible. Additionally, app attribution – the link that shows up under content shared/posted via the app – would only link users back to the main domain, and not to your customer’s.
You would not be able to use the JS SDK for client-side API requests, or even just to embed it to render any of the FB social plugins that require an app id – the SDK checks what domain it is “running on”, and can not be tricked to accept a domain that is not specified in the app settings.
There could be privacy issues. An over-exaggerated example: Just because I as the app user decided to share my photos or videos I have on Facebook with your customer Our-Holy-Mother-of-Christ-Bakery.com, does not necessarily mean I want to share them with your other customer, amateurs-doing-all-kinds-of-nasty-stuff.xxx as well – but if they shared an app id for login purposes, I automatically would. Have fun writin’ the Privacy Policy (which is mandatory if you use FB login functionality, and FB also automatically checks if your app has got one) for that scenario ;-)
Finally, and most importantly: All your customers would be “sitting in the same boat.” If one of them, or in turn their website users, would publish spam via your app id, so that Facebook blocks it, login would not work any more for all of your customer’s websites. And if you decide only then, that setting up an individual app for each of your customers would be the better way to go, they would not be able to recognize their existing users any more, because of user ids being app-scoped since API v2.0 was introduced – so if users logged into this new app, that app would see a totally different user id. (And to rely on an email address as an identifier is risky, too, because you will not get one from the API for every user; for example if they registered using their mobile device.)
Edit: Plus, app/domain insights, as luschn mentioned in his answer.
¹ Yes, the review process has made it more laborious to set up multiple apps for multiple clients. But for apps that do the same stuff/use the same permissions in the same manner, you can refer to an earlier successfully reviewed app id to speed up the process a little. Also, screenshots of how f.e. posts made via the app look on timeline, and what UI components are used, as well as screencasts that you include in your submission could probably be used with little to no alteration.
Apps are not meant be used on several different domains, you will have to create a new App for each domain, i´m afraid. You can use the different platforms in the App settings to use different domains, but there are only a few so it´s pointless. Just create some screenshots and a tutorial for your clients, that´s how it is usually done.
Btw, it would be weird to authorize an App on a website, and the same App would allow you to be authorized on all other client websites. Also, insights are per App, so your clients may want to see their own insights and not the global insights of all domains together.
Many is not defined but i think for being a smart developer you need to create new app_ids for every project you need to use facebook connect. Just my opinion. It also allows you to monitor alot of stuff.

What parameters are allowed in Desktop web game policy change?

We have a browser based game which uses Facebook Connect through an AppID that we used to run the same game in a canvas until Fb Credits were introduced and we were forced to shut it down. Now, we only use the App the same way as a product page with the FbConnect integration on our own site.
Today's mail states for our case:
If your Connect app is accessing user connections or asking for additional permissions beyond age, email, and our Publishing Permissions, please remove these requests.
(This refers to this policy change: https://developers.facebook.com/blog/post/2012/09/05/platform-updates--operation-developer-love/)
We are using oauth FbConnect with scope=email,user_birthday. This is exactly what was specified in an earlier mail so it should be ok.
Once the user is authenticated, we simply call
https://graph.facebook.com/me?access_token=...
and read what comes there.
Is it possible, that we are not allowed to call the GraphAPI's me anymore? It contains info like gender, location and locale...
The Oauth data contains the fbuid, first/lastname and the email, but it does not contain the age, what we are supposed to be allowed to ask?
Do I have to call https://graph.facebook.com/me?fields=birthday explicitly?
Did anyone actually succeed in getting an "desktop web game hosted primarily off Facebook" to comply with their new policy without creating a new AppID?
Note: There have been a couple of questions about the "Sep 5th policy change" like Facebook: Notice of Violation this one and many previous closed as duplicates, but none I found so far contains questions or answers on a technical level.
Maybe you could skip the "Website with Facebook Login" part in developer settings and only provide your game directly via canvas. (eg. apps.facebook.com/logogame). that's what "on facebook.com" is all about, I guess.

Support for multiple domains does not work as advertised

In October, Facebook announced support for multiple domains for a single app. This is great news for developers whose apps have multiple domain aliases - no more iframe hacks to get the JavaScript SDK working regardless of which of your domains the user is viewing the page from!
Unfortunately, it does not seem to work as advertised.
In the blog post, they say:
Your App’s URL (Website and/or Mobile Web URL) must be derived from one of the domains listed in the App Domain field.
Which is reasonable enough, but the form in the developer app seems to be enforcing the converse policy. I have a pair of domains (say, abc.com and xyz.com) and the site URL set to (http://abc.com), and when I save I get the error message:
xyz.com must be derived from your Site URL or your Mobile Web URL.
Does anyone know a workaround for this problem? Or is this what they intended and the content of the blog post is wrong? If so it seems pretty silly, since it's hard to have multiple domains be derived from a single site URL.
I commented on the blog entry hoping that a Facebook engineer will see it... but in the mean time...
This is a known issue and is filed under
https://developers.facebook.com/bugs/288905901157023
You can help raise awareness and get it fixed by visiting the bug link on facebook and subscribing to it; facebook prioritizes defects by number of subscribers, so raising this number will also raise priority.
Please click the link above and subscribe!
Thanks!
A.
Yeah it's true enough that
Your App’s URL (Website and/or Mobile Web URL) must be derived from one of the domains listed in the App Domain field.
But their documentation should spell out that it's more like the other way around: the Site URL (and Mobile if present) dictates what domains are permitted in App Domain field, and they all have to be derived from the Site/Mobile URL. So you got it right, a.bc.com and d.bc.com would be allowed but not x.yz.com