Hi everyone!
I have a similar issue. It’s not the URL . I get the error message for URI. Any help please?
This redirect failed because the redirect URI is not white-listed in the app’s client OAuth settings. Make sure that the client and web OAuth logins are on and add all your app domains as valid OAuth redirect URIs.
Thank you!
Alex
A screen shot would be better so we could see what you did wrong
I just don’t know where to get the URI from when Facebook asks for it:
just copy the exact url from the browser and paste it there when you preview the page(index)
Thank you! That solved it!
When I make the app go live, I’ll have to change that address, right?
Yes. Same way:grinning:
Everyone THANK YOU. I cant tell you how many times I’ve read and reread the manual and reference regarding api and the amount of youtube videos I’ve watched trying to figure all of this out. Yet I still suck and can’t get it to work.
SO
I was having the same error message that @AlexDaresTo was having:
I made sure to apply all of the suggested settings, but still I couldn’t get mine to work. Thus, I went to the plug-in section on bubble and saw that I had checked off the box stating:
“Use a generic redirect URL (http://myappsname.bubble.io/api/1.1/oauth_redirect)”: in my initial attempt of just trying different settings to see what would or wouldn’t be the issue.
If you are following this advice, it is out of date now. For some reason Facebook have become very sensitive about apps posting on behalf of users, no idea why maybe they had some sort of scandal 
Anyway, the issue is with some of the scopes that the “Facebook Complete” plugin is requesting. They have either been deprecated (you can’t post on a timeline now) or firewalled (posting on a Page).
Scopes are just the things you are asking Facebook to be able to do on behalf of your user. Some fairly innocuous "user_about_me " some are BIG “manage_pages”.
If you request one of the firewalled scopes then you now need to get your app (as in app on Facebook developers console) authorised for it to go in to “live”. If you keep it in development then only the facebook users you tell facebook are your developers will be able to test these actions.
And this is what the message is about.
If all you want to do is “login” with Facebook, and not post on pages etc, then revert to using the Bubble plugin. The “Facebook complete” one is now out of date after the current changes.
So I jumped into the middle of FB Oauth there, so thought I would back up a little.
Oauth is big and scary, but also quite simple as Bubble users tend to access it in the same way because most Bubble apps are web pages. So once you get it … you get it.
The difficulty with thinking about how it works, from a Bubble perspective, is that you have to split your app in two for the purposes of understanding the “dance”.
If you are a traditional developer, with a split between the front and back end devs (you may not even be in the same country, let alone the same room), it is much easier to think about.
So…Your app has two parts, the web page bits and the workflow bits.
Now for the tricky bit… we don’t trust the web page bits. Bad guys can mess with it. We DO trust the workflow bits. Which is odd for us as they are all the same app as far as we are concerned.
Ok, so this is problem, as the trusted bit isn’t in the browser. And we need the browser to be able to redirect the user to another browser page (to log in) and then back to our page.
So we give the browser some of our information, and let it ask Facebook to sign our user in. It does that by simply asking to go a facebook webpage (ok, it isn’t exactly a “page”, but it looks like one for our purposes).
If you are fast enough, you can grab the redirect URL when you hit the “sign up with Facebook” button. And actually you could dispense with Bubble entirely and just take your user to that URL.
Off we go to the “authorise page”. We tell it who we are (client id, this is totally not secret) and what we want to do (scopes) and where to come back to (redirect_uri).
Our untrusted web page hasn’t got anything secret to worry about. It is easy to replace your webpage with my webpage. I can use your client id as much as I like. This is all public.
Facebook’s authorisation page checks out the client_id (yeah, looks legit) and then matches the URL you said to come back to against the list it has. It has to match exactly, and will get fussy about version-test and ?debug_mode and whether it is http or https.
So if you are having redirect url issues - try to grab the browser URL just after you hit the signup button. That will have the redirect URL in there. Now carefully check that against your app settings in the dev console.
Right, so we check out OK. Facebook asks the user to login, and then it passes control back to the page you specified. And it also passes back a code. Not a secret, it is still in our browser address so I can easily steal as many of your codes as I like. But unique.
We now have to do the secret bits, not trusted to the browser. Our web page passes this code to the back end.
The back end now has a “machine to machine” chat with facebook’s “token” service.
“Hey Facebook, my untrusted front end reckons it asked you for a code, and you gave it this Oh by the way here are my secret passcodes to ensure you know I am who I say I am. Just between you and I, is this legit ?”.
“Yes, that all checks out. Here is really secret token but please keep it really safe and don’t tell your front end”.
And then…
“Hey Facebook’s User details service, I have this super secret token, can you tell me everything about this user please”.
“Sure, that still checks out, here you go”.
In fact Bubble doesn’t even really trust us all that much, so we never get to see that super secret token in most normal situations. It hides it from us.
ok I uninstalled facebook complete and installed the facebook plugin.
Now,
For the snatch and grab method…
dumb question:
I see what you mean about it having the uri that I need to pluck out and paste into my uri settings. For example I’ll paste below my url that I managed to snatch. Ill replace what might be sensitive numbers with the number 8 and what Im anticipating should be the important part that I need to extract will be bolded and italicized. Also for reference Ill have my original url posted right above it.
Also I originally thought that it ended at the “oauth_redirect” bit (which is where I have my italicization ending, however I noticed that the bits about “version test” are nowhere to be found and that the “debug_mode” is further down… So then I thought I’d play around with it since I have the option of adding in several uri’s on facebook’s settings (yes, I did remember to hit save, eventually), but alas, no combination seems to work.
original: https://myappsname.bubbleapps.io/version-test?debug_mode=true
plucked version: https//myappsname.bubbleapps.io/debug_mode=true
https://www.facebook.com/dialog/oauth?client_id=888888888888888&redirect_uri=**https%3A%2F%2Fmyappsname.bubbleapps.io%2Fapi%2F1.1%2F**oauth_redirect&response_type=code&state=%257B%2522debug_mode%2522%253A%2522true%2522%252C%2522oauth_provider%2522%253A%2522facebook%2522%252C%2522resume_key%2522%253A%88888888888888888x247%2522%252C%2522used_redirect_url%2522%253A%2522https%253A%252F%252Fmyappsname.bubbleapps.io%252Fversion-test%253Fdebug_mode%253Dtrue%2522%252C%2522redirect_unique_id%2522%253A%88888888888888888x8888888888888888%2522%257D&scope=email
meh?
Hey Ali,
Here are the settings for a FB login using Bubble’s Facebook plugin:
Facebook App
The value for Valid OAuth Redirect URIs points to the Bubble page where you are triggering the social login action noted below. What you see in my sample is three URI’s: One for version-test with debug on, one for version-test with debug off, and a third one for the live site with debug off. All of them, point to fb-basic, which is simply the name of the Bubble page I setup – use whatever you want, just make sure they match.
Bubble
Install the plugin
Set the app id and secret on the plugin parameters page using the values from the fb app
Use the social login action to connect a user
That should get you going!
I would be tempted to turn the “use the generic redirect” OFF.
Your app is wanting to redirect to …
https://myappsname.bubbleapps.io/api/1.1/**oauth_redirect
Do as Ken says, and add the 3x URLs as above, based on the page your button is on.
Ha! I didn’t even see that the plugin supported the generic redirect like the api connector.
@NigelG I just switched it to generic and it works fine. Have you had bad luck with that?
IT WORKSSSS
Ok so I tried both using and not using the generic oauth redirect. Still didnt do anything, but I noticed that you suggested to turn off “Embedded Browser OAuth Login” in your settings (which someone else had directed otherwise- I think it was this thread actually). But I turned mine off, and tested the generic “https://myapps name.bubbleapps.io/api/1.1/oauth_redirect” in the Redirect URI Validator.
