I am using the Facebook JavaScript SDK for a project I'm currently working on. It's been working fine before, but when I opened it today, the URL http://connect.facebook.net/en_US/all.js is not accessible. When I inspected the network using Firebug, I noticed that the server was returning 403 Access Denied.
Is there something I am getting wrong or is it Facebook server problem?
Finally figured out that Facebook's new HTTPS feature is interfering. Using https://connect.facebook.net/en_US/all.js solves the problem. Seems someone misconfigured their servers.
Related
I am developing a web-app which will manage user page posts etc,
My app in Facebook developer console is in development mode, but when i try to login in http://localhost then it gives error that facebook login does not allow http but i have to use https protocol.
Any solution to test facebook login in localhost with http ? or
Any idea to convert http to https in localhost?
I tried ngrok that converted http to https but facebook developer console said it is suspicious kinda link and refused to accept;
I am using a npm pakage react-facebook-login,
I will shift to pure code of facebook sdk if that will solve problem.
This is a solution I found for create-react-app. https://create-react-app.dev/docs/using-https-in-development/
Make sure you use the right terminal and it works. For instance, I started dev in the cmd line (set HTTPS=true&&npm start).
The downside is you still will get not secure warnings in the browser but the errors with the FB.login or similar from Facebook login packages went away. Hope it helps.
I've recently integrated play-silhouette 4.0.0 with Play 2.5 to handle authentication. I am allowing my users to login with Google and as such am using Silhouette's OAuth2 features. I am redirected to Google's authorization page properly but after pressing allow the app fails with
403 - Project marked for deletion
I have enabled the Google+ API in the developer's console and am requesting the scopes "profile email" from the service. I've also deployed the sample app and get the same error. The error codes listed by Google are not much help - anyone have an idea? I've been testing on my local machine.
I resolved this issue:
Create a new project in the Google Developer Console.
Enable Google+ API.
Create OAuth Credentials.
Perhaps I created the credentials before I enabled the API. Seems a bit silly order would matter. Hope this is helpful to someone else!
I am developing a Telco application (Dyanamic Web application project to send and receive sms) using Eclipse & tomcate version 7
When I try to run it on
http://localhost:8080/SMS1
It gives an error message HTTP-ERROR-CODE:302
What should I do to resolve this error
This is the link to Application and video tutorial what I am following
https://drive.google.com/file/d/0B3VmCeqDC7SDcFZaWVZhRUNmaTQ/edit?usp=sharing
HTTP code 302 is a standard "redirect" message--that is, it tells your web browser that the page was moved and where the new page can be found. I'm guessing whatever you're using as a web browser (Eclipse?) just doesn't handle that type of redirect. Try using a standard web browser like Chrome or Mozilla to see if that helps...
Also a guess, but the redirect may be trying to move you to HTTPS instead of HTTP, and your certificates may not be set up properly, or the port isn't enabled, or there may be some other problem with your HTTPS configuration. If the app is supposed to work over HTTPS, try going directly to the HTTPS version of the link to see if that's the real issue.
A third guess is the app may be trying to redirect you to a login page if you're not logged in, and maybe it can't find it. I'd need to know a lot more about the built product and I really don't want to mess with some guy's shared Eclipse project. Tell them to use a build tool!
I have a Facebook canvas app that calls various external files over https. When loading FB over http and then navigating to the app, I get the message "Internet Explorer blocked this website from displaying content with security certificate errors."
I realize there could be any number of culprits in a mixed environment, but how to best troubleshoot the specific request(s) that trigger the error? The IE dev tools don't provide a clue, as the error is not reported in the network or console tab. When I view the same page in Chrome, I get no SSL error, so I can't find a clue there.
Essentially what I've done so far is to proceed by clicking "show content", logging all the https requests in Charles, then trying them all individually in IE to see if any trigger the error out of context.
thanks
The F12 Tools Console typically will show the exact source of a HTTPS error, as will the Fiddler Web Debugger. Is there a repro URL we could look at?
Do you have fiddler or httpwatch to figure out whether the request is being forwarded to another secured (https) URL?
Is it possible to develop facebook using google app engine locally, without having to upload application every time I change it?
I assume you are getting API error 191 when you try to access the Facebook API from the dev appserver?
API Error Code: 191
API Error Description: The specified URL is not owned by the application
Error Message: redirect_uri is not owned by the application.
If you are developing on your localhost, you can set the 'Site Domain' field in your facebook app settings to (appname).appspot.com and then edit the HOSTS file on your system.
In my environment I just entered:
127.0.0.1 devlocal.(appname).appspot.com
As long as the browser's URL matches *.(appname).appspot.com, it will work.
You could set the Website field in your Facebook app settings to http://localhost:XXXX or http://127.0.0.1:XXXX for development and then change it over to the actual once ready for deployment. This worked well for me.
I ran into this issue a couple years ago and wrote a long article about how I solved it for my needs.
http://www.upwithabang.com/articles/GAE-facebook-win7.html
It covers the setting up of an Apache server on your laptop then telling Facebook and the GAE to behave as if it hosted on a production server. This solves the pain of constant uploads for testing every little change.
Hopefully this is helpful to someone, if not a little late.