I am using facebook SDK. I am getting the following error:
Insecure Login Blocked: You can't get an access token or log in to this app from an insecure page. Try re-loading the page as https://
After studying I came to know that I have to set 'Enforce HTTPS' as NO under 'facebook login> Setting> '. But I can not set Enforce HTTPS as NO. Is this problem is from mine? OR I facebook restrict to use https instead of http?
enable Client OAuth Login and write "localhost:3000" in Valid OAuth Redirect URIs.
Save changes. it will automatically change to https://localhost:3000 , but it doesn't matter...
And set Status: In Development (THIS IS IMPORTANT!)
Then it will work in your http localhost.
But I can not set Enforce HTTPS as NO. Is this problem is from mine?
https://developers.facebook.com/docs/facebook-login/security:
Enforce HTTPS. This setting requires HTTPS for OAuth Redirects and pages getting access tokens with the JavaScript SDK. All new apps created as of March 2018 have this setting on by default and you should plan to migrate any existing apps to use only HTTPS URLs by March 2019.
Sounds to me, like they don’t want you to be able to even start without HTTPS, when you are creating a new app now.
Plus, Chrome has recently announced that they will mark all HTTP sites as insecure soon, from version 68 on, that will be released in July 2018. So you’re gonna have to go HTTPS rather sooner than later anyway.
The “big players” of the industry are currently pushing for this big time, whether we want it or not.
If you just enable Client OAuth Login and write just localhost:{port} to Valid OAuth Redirect URIs, it will work.
If you're developing locally with create-react-app, a quick solution is to add
HTTPS=true
to your .env file and just comment it out when you're not testing Facebook login.
It seems like Business apps do not have app modes and instead rely exclusively on access levels. Because of this, you can't set the app to the "Development mode".
All newly created apps start out in Development mode and you should avoid changing it until you have completed all development and testing.
https://developers.facebook.com/docs/development/build-and-test/
https://developers.facebook.com/docs/development/build-and-test/app-modes
However, if you wanna try out your app in a localhost, you need to create a test app, like you can check out in this thread:
How to fix 'Facebook has detected MyApp isn't using a secure connection to transfer information.' error in Laravel
Related
The “WP Mail SMTP” revoked the connection from my G-mail account again and again.
No password changed.I missed my order notification again and again.Please tell me why it is happening.
WordPress Version:- 5.6
PHP Version:-
WP Mail SMTP Version:- 2.6.0
Web Server:- Apache
PHP version:- 7.3.5
License key type:- lite
To solve it I accessed WP Mail SMTP settings on WP Admin Dashboard and, in the Authorization, pressed "Removed the Connection"
And then allowed the connection again ("Allow plugin to send emails using your Google account")
And that redirected to the following screen (after login), and had to allow
Note: One needs to be in the Google Account that one configured the API (see here how to configure WP Mail SMTP for Google Workspace/Gmail Mailer)
Token has been expired or revoked, but it is hard to know exactly what is the problem.
My guess is that it could be happening for a variety of reasons, such as resetting the password of the account one is using.
A WPMail SMTP creator wrote (here) the following:
Hi everyone,
it looks like this is happening to more and more users, but we don’t
know what the reason behind this account disconnect is. We have a lot
of testing sites set up, and we never experienced this issue. I just
rechecked my testing sites.
One of the main things that could cause this issue is if your
Google/Gmail API app is in “Testing” mode. Could you please check if
the google API project is in the “Production” mode by going to the
Google API console, opening the project for our plugin integration,
then go to “OAuth Consent Screen” and check the “Publishing status”.
More info can be found in this screenshot. It should say “In
production”.
If that’s not the reason, then we have to go over all the Gmail API
project options together and see what the differences are. I think it
has to be something on Google’s side since they are the ones that
invalidate the token, not us.
And to answer bst7’s questions: The Google API app is created by you,
to be used just by you, even though on the free Gmail accounts you
have the app set to “External use” (no other option is available), but
nobody else will use this app apart from you, since you are the only
one that knows the project credentials and have logged into it from
your secured WP admin dashboard.
Our plugin requires top-level permission because that’s the best way
to future-proof our plugin development. If we were to improve our
plugin and would have required only the minimal permission level, upon
the plugin update, your connection would be invalidated and the newly
added plugin functionality would not work. For example, we added the
support for aliases a few versions ago and if we didn’t have the
top-level permission, after the update all users would have to reset
the connection manually in order for the Gmail mailer to work properly
again. It’s just a way to make sure we can keep improving our plugin
without any issues for our users.
However, in my case the Publishing status is "In production" and the problem also happened.
I am developing an ASP.net web app which uses Facebook authentication and up until August or September the Facebook login feature was working correctly.
I took a break from developing the app for a month or so, and recently resumed development. I tried it again recently to login to the app with Facebook, and I get this error message:
"URL Blocked: This redirect failed because the redirect URI is not whitelisted in the app’s Client OAuth Settings. Make sure Client and Web OAuth Login are on and add all your app domains as Valid OAuth Redirect URIs."
I haven't changed any code from my app since September or August, so something must have changed in the way Facebook processes its logins.
I have made changes to the Facebook app settings to try and fix this but nothing works.
My current settings look like this:
Client OAuth Login: Yes
Web OAuth Login: Yes
All the other settings under the Facebook Login product are set to No.
My current redirect URIs look like this:
https://myapp.azurewebsites.net/api/ExternalLogin/Facebook
https://myapp.azurewebsites.net/api/ExternalLogin/FacebookCallback
https://myapp.azurewebsites.net/api/signin-facebook
https://myapp.azurewebsites.net/api/ExternalLogin/Facebook/signin-facebook
Originally I only had the "/FacebookCallback" URI. I only added the others following suggestions from other questions here on Stack-overflow, but I am still getting the same error message.
Can anyone help me figure out what am I missing?
Please make sure:
Your App IDs and Secret Keys are correct. The App IDs and Secret Keys are all different for each app. These often cause the problem.
Your App domain set to:
myapp.azurewebsites.net
Your site URL set to:
http://myapp.azurewebsites.net/
You have set URI properly like:
http://myapp.azurewebsites.net/facebook/login/callback/
Update:
Make sure you have placed / at the end of your all URIs.
https://myapp.azurewebsites.net/api/ExternalLogin/Facebook/
https://myapp.azurewebsites.net/api/ExternalLogin/FacebookCallback/
https://myapp.azurewebsites.net/api/signin-facebook/
https://myapp.azurewebsites.net/api/ExternalLogin/Facebook/signin-facebook/
OR
localhost:44396/api/ExternalLogin/FacebookCallback/
I have a Comodo SSL certificate on my host plan, however when accesing my site from google, it sends me automatically to
http://example.com, Where the green lock doesn't appear.
If I manually add "https", like: https://example.com it does show up!
Is there a way to access my website always with the green lock showing up? instead of manually having to write it everytime?
You can easily redirect to the https version of any page using rewrite rules/rewrite module of your web server (the exact way to do this depends on the webserver used). Ask your provider, this is a common case so there may even be a UI option in your console to do this.
Regarding google see this: https://webmasters.stackexchange.com/questions/67212/how-to-convince-google-to-list-https-version-of-website
It may also be good form to verify the protocol used to access the site in your authentication module and refuse authentication if the wrong protocol is used. Assuming web rules are used to redirect traffic this would to prevent leaking information due to a misconfiguration/bug.
How to prevent someone just taking my API keys from the client side javascript code and starting to use my HERE subscription for some other use.
I noticed HERE provide an option to secure the API keys for a certain domain on the applications management page: "Secure app credentials against a specific domain". I have set up this option and also put domain there but I do not see any change on my app behavior.
The application still continue working fine on my PC. Shouldn't the HERE API stop working as web server is running on localhost and not on the defined domain.
My app is running fully on browser, and only static files come from the server (http://localhost:8083/index.html). I am using the HERE javascript API.
I tested also running the app on external cloud service on different domain than localhost. Results are the same. My conclusion is that the setting "Secure app credentials against a specific domain" just has no impact and does not work. Checked also the api response headers and all origins are accepted.
Access-Control-Allow-Origin: *
In your HERE dashboard, you can set the application id and application code to only work on a particular domain or set of domains. If the tokens are fixed to a domain, it won't matter if someone takes your tokens because only the listed domains can use them. If you don't secure the tokens to a domain, then someone will be able to use your tokens if they find them.
I have some JS that is on some intranet application that's running on HTTP (this server/service is out of my control, run by the customer). I operate the internet application and it must run on HTTPS for security purposes.
I'm attempting to use XDomain but I'm finding that the cookies aren't being sent. Is the problem that I'm going intranet to internet or that I'm going HTTP to HTTPS or some configuration problem?
I keep getting 401 when checking authentication of the user even after they have logged in.
I've verified the backend/internet service works as expected via a jsfiddle (i.e. Access-Control-Allow-Origin, etc. are all correct).
Thanks!
There are some security related issues with XDomain that makes it strip any cookies according to no 5 in this msdn blog. However there also exist a workaround using proxy with example project on Github. I think everything you need to make it work are described in those two pages.