I am building a facebook app. I don't have https. But It was working well before few minutes. But now when I try to access the app as https://apps.facebook.com/reelreview/ it shows an SSL error as
Secure Connection Failed
An error occurred during a connection to www.synergiadigital.com.
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
I know it is due to the lack of https, but my doubt is that it was working well before few minutes. And also was working well for the last few days. Suddenly it shows the error.
I am not able to find the exact reason and solution,
Please help me ,
Sincerely,
Sunil
Have you checked your Account Settings -> Security -> Secure Browsing? Maybe by mistake you've changed it to "Browse Facebook on a secure connection"?
This is not directly an answer to your question which is about an app - but answering anyway, since this is one of the top hits on google for the error message.
The error can be caused when a plain HTTP response is being received on an HTTPS (SSL) connection. The site is configured for HSTS, so a browser which has accessed the site previously will upgrade from http: to https: even before making an initial connection there, without a redirect.
In my case, Firefox gave Error code: SSL_ERROR_RX_RECORD_TOO_LONG when the parental controls on the TP-Link household router was blocking the site, sending a "site blocked" response page on http: despite the connection being https:
This was reveled using another browser which had not been used before (MS Edge), which did not know about the HSTS setting (it had never visited facebook.com before) and therefore followed the redirect back to the router parental controls error page showing a more user-friendly message:
Related
I have searched for this and found answers that do not work in my case. I would appreciate some thoughts on this
I have set up a github page at: https://ir-ischool-uos.github.io/mwpd/
Some users reported that when they visit the page, an error about security is displayed, like this on Chrome:
- However, many users say it works ok for them.
I have found some sources say that this only happens if your link contains 'https' instead of 'http', but tested on two computers, one mobile phone and one tablet they both work fine. I also found source that say I should use GitHub page's https support, and I checked my setting this already is ticked.
Is there anything I can do to fix this for every user?
Thanks
This error could happen because of numerous of reasons. For example:
The server certificate (or at least one of the certificates in the chain of trust) is not among the trusted certificates that the browser/system maintains (maybe an outdated list?). Try to update the browser/system.
The date/time on the system is not configured correctly.
The connection is being intercepted (by an attacker?) and the certificate is manipulated, hence the SSL connection handshake process could not complete.
Your connection is not private error appears on websites using the SSL / HTTPs protocol when a browser is unable to validate the SSL certificate issued by the website.
Basically, any website using SSL / HTTPs protocol sends a security certificate information to users browsers upon each visit. Browsers then try to validate the certificate using the public key accompanying the certificate.
If it checks out, then users browser encrypts the data using the private key sent by your website. This encryption secures the data transfer between a user’s browser and your website.
I have checked it accross 3 different connections and they all worked just fine.
I believe the problem could be from the users. They may need to clear their cache, check if their clock is set correctly, their antivirus could be stopping it. And their browsers may be outdated.
What I will advice is just (https://support.github.com/contact). They could check to verify if this is an issue from the server or not.
But from what am looking at, this may be an issue with the user's device.
Also here are a few links you could refer and see if all settings on your own part are rightly set;
[1] https://github.com/docsifyjs/docsify/issues/236
[2] https://help.github.com/en/github/working-with-github-pages/securing-your-github-pages-site-with-https
[3] https://help.github.com/en/github/working-with-github-pages/troubleshooting-custom-domains-and-github-pages#https-errors
I hope this helps. Let me know!
If you are using a school/college wifi, most probably someone has your credentials and he/she is using it at the same time as you so basically when he/she is using the web you'll get this message, you should probably change your password or switch on VPN.
If the WiFi/other network used to access the website in question is a school or public network, some 3rd-party software used by it's administrator might be trying to prevent or override the connection to your website.
That might happen in order to display an error message (e.g. "Website access prohibited"), a captive portal (network login window), or just to watch the data being sent around.
Since you're using HTTPS it was prevented when the certificate check failed, because with HTTPS in place that software has no way of presenting it's own page or eavesdropping, other than creating it's own certificate with your website name in it on the fly. Which, of course, was rejected by the browser, since either the user didn't expect it, or, if it's indeed a school/company network, the PC wasn't properly enrolled for use on the said network.
Either way, there is no problem with your webpage itself. Because Github manages the server for your Pages, chances you could create something causing that problem yourself are pretty much zero.
Sometimes it happens because of the wrong IP/DNS settings. Checking the below places might help resolve the issue:
Make sure you are using a common public DNS server. How to check the DNS server you are using depends on your operating system. Moreover, if you are using a VPN client and it has a DNS configuration, check that setting too.
Check if there is an IP address associated with GitHub in the system's hosts file. In Linux and macOS you may use sudo vi /etc/hosts. If there is one, turn that line into a comment by adding # at the beginning of the line. Save, exit, and check if you see that error again. Do step 3 only if you are still getting the same error.
Go to https://www.ipaddress.com, search for github.io, and add its IP address at the bottom of /etc/hosts file like this example: 140.82.114.4 github.io.
Hope this helps.
I spent the last day and a half researching this problem to no avail. I found many similar problems, but none that exactly address my issue. I am attempting to integrate Payflow Pro with transparent redirect, but cannot successfully complete a transaction. I am using the test environment with a test Payflow Gateway account.
I can successfully retrieve a secure token by posting the following from my test server to https://pilot-payflowpro.paypal.com:
PARTNER=[hidden]&VENDOR=[hidden]&USER=[hidden]&PWD=[hidden]&TRXTYPE=S&TENDER=C&CREATESECURETOKEN=Y&SECURETOKENID=20180916085333999&URLMETHOD=POST&SILENTTRAN=TRUE&AMT=2&BILLTOFIRSTNAME=John&BILLTOLASTNAME=Doe&BILLTOADDRESS=123TestDr.&BILLTOCITY=Testcity&BILLTOSTATE=TN&BILLTOZIP=55511&BILLTOEMAIL=johndoe#test.com&USER1=3&USER2=&USER3=0&USER4=2
to which I receive the following response:
RESULT=0&SECURETOKEN=[hidden]&SECURETOKENID=20180916085333999&RESPMSG=Approved
NOTE: I have configured a Return URL using PayPal Manager, which is why RETURNURL is not included in the secure token request. However, I also have tried with RETURNURL specified, and I have obtained the same end result.
I use the results from the secure token request to create a cc collection form. I input test credit card details using acct# 5105105105105100, then post the following from the browser directly to https://pilot-payflowlink.paypal.com:
fund_id=3&ACCT=5105105105105100&CVV2=555&EXPMONTH=01&EXPYEAR=20&EXPDATE=0120&SECURETOKENID=20180916085333581&SECURETOKEN=[hidden]&feeTokenID=20180916085333999&feeToken=[hidden]
The response is properly redirected to the Hosted Page error URL I have specified in my Payflow Manager Service Settings. My problem is that I do not understand why it is redirecting to the error url with the following message:
RESPMSG=Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com:443
NOTE: The value above is only one part of the response sent to the error page. The rest of the return values include information from my original secure token request, which I would assume could only be returned if a successful connection had been established with the link in the error message??
To clearly state the problem:
I have already successfully connected from my test server to the link specified in the error message, when first I obtained the secure token.
The post that results in the error message was sent from the browser (in this case, on the same physical box as my test server) to https://pilot-payflowlink.paypal.com, which is not the URL specified in the error message.
Finally, the error seemingly occurs during the Payflow process - to my understanding, there should not be a call from my server or the browser to the link in the error message at this point during the process. I mention this specifically to address the many search results I found relating this particular error message to PayPal's requirement for TLS1.2, which is already properly configured on my server (I should mention for the sake of completeness, I do still have TLS1.0 enabled on my test server, but cannot disable it for unrelated reasons. Nonetheless, I was able to successfully connect to obtain a secure token, and my server passes PayPal's own TLS test at https://tlstest.paypal.com/).
I should mention that I also have tried to complete this same transaction on our production server, still using test credentials and test endpoints at PayPal, with exactly the same results. The test server is also set up for TLS1.2 with TLS1.0 enabled, and also passes PayPal's test.
This problem may be the one that pushes me full-on into insanity, so any help really would be appreciated!!
Disabling TLS1.0 has helped others with this issue. If you keep having problems, contact PayPal's support
For anyone who might find this question and be similarly frustrated, I want to share that I was able to solve the problem by creating a new Payflow Gateway test account.
I spent a great deal of time on trial and error solutions with no success, and PayPal Merchant Technical Services was able to duplicate the problem but was also unable to find a solution. Finally, after simplifying my test app as much as possible (two bare-bones HTML forms filled in and submitted manually), I came to the conclusion that there might be something wrong with my test account. Upon creating a new account with new credentials, then inserting them back into my original code, everything worked perfectly.
As of this morning, PayPal MTS is continuing to research the problem, since others have reported similar issues.
For others with similar problems, it is worth noting that I am now able to complete transactions while TLS 1.0 remains enabled.
My weather app using the yahoo API worked fine for the last year using OAuth protocol. It suddenly stopped working working yesterday throwing this:
System.Net.WebException: The remote server returned an error: (502)
Bad Gateway.
weather.yahooapis.com also returns
Connection refused Description: Connection refused
Any idea on what the problem could be; if its on my end or an issue with yahoo?
The problem is probably on the Yahoo end.
My application broke too. I have temporarily fixed the problem by replacing weather.yahooapis.com to weather-ydn-yql.media.yahoo.com. The endpoint URL which was exposed previously is down today, I found alternative working URL through some google searches (apparently it seems they have updated their android mobile app yesterday which may have broken this, don't know guessing this based on google search results).
Anyhow, Yahoo weather developer document now recommends not to use weather.yahooapis.com and use instead YQL
You can use below URL for as per YQL recommendation instead of
Old URL
http://weather.yahooapis.com/forecastrss?w=2502265
New recommended URL
https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%3D2502265
Here, parameter w is WOEID.
We are implementing a Facebook application where AS3(XIFF 3.1.0 lib) is used to login to Facebook chat so that the App may send some notifications to the user's friends. At this point we come across a problem regarding a cross domain policy file required by Adobe. The thing is, when the request to get a cross domain policy file from chat.facebook.com (using
Security.loadPolicyFile("xmlsocket://chat.facebook.com:5222") ) is answered from an IP address other than 69.171.241.10 the zero byte terminating the policy file is missing in the response from the server(e.g. 173.252.107.17:5222).
According to Wireshark the flow looks like below.
Request:
<policy-file-request/>
\000
Response:
<allow-access-from domain=\"*\" to-ports=\"5222\"/>
According to the Adobe recommendation "The server must send a null byte to terminate a policy file, and may thereafter close the connection; if the server does not close the connection, Flash Player or AIR does so upon receiving the terminating null byte."
Assumption: As a result the flash player considers that no policy file is received and doesn't process xmpp login to Facebook chat.
If the assumption is correct then it looks like a Facebook bug.
Any help would be greatly appreciated,
Thanks.
This does appear to be a Facebook bug. I've verified this by performing a Wireshark link against the Openfire XMPP server (which works correctly). Have reported the bug with FB:
https://developers.facebook.com/bugs/707541335928781
Good News!!!
Facebook has fixed the bug.
I am trying to send emails from Django using an email configured by Google Apps, my configuration at the settings.py file looks something like this:
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'contact#mydomain.com'
EMAIL_HOST_PASSWORD = 'password'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
When I try to send an email using:
from django.core.mail import send_mail
send_mail("Happy new year", "We wish you the best for 3001",
"contact#mydomain.com", ["someuser#gmail.com"])
I get the following error:
SMTPAuthenticationError:
(535, '5.7.1 Please log in with your web browser and then try again.
Learn more at
5.7.1 https://support.google.com/mail/bin/answer.py?answer=78754 k2sm758604obl.14')
Since I'm working on a remote server with no graphical user interface, I cannot even try to login from the browser.
Just go to
https://accounts.google.com/DisplayUnlockCaptcha
and click "continue". This is going to allow access from other servers.
I've been messing with this for a couple of hours within a cucumber/capybara/selenium test - discovered something stupid which will fix this error for good, guaranteed
The all too familiar error:
Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure) (Net::IMAP::NoResponseError)
As it turns out, there are TWO "Allow Less Secure Apps" toggles which need to be changed to allow logins from unknown devices/IMAP.
One here: https://myaccount.google.com/security?pli=1#connectedapps (bottom of the page)
And one here: https://www.google.com/settings/security/lesssecureapps
BOTH OF THESE GODFORSAKEN TOGGLES need to be changed to get rid of this error message.
edit: from user Milothicus (https://stackoverflow.com/users/3538026/milothicus): in myaccount.google.com, under 'Sign-in & Security', select 'Connected apps & sites'. this also has an option to 'Allow less secure apps'. after turning this one on, my server could now send me an automated email.
When I tried to access my account I was sent this email consisting of this link.
https://www.google.com/settings/security/lesssecureapps
You can turn-on then possibly turn-off after you've done testing.
I got the following response from Google Apps support:
You need to turn on your Outbound relay. To do this:
Log into your account at google.com/a/yourdomain.com
Click the Settings tab and then select Email in the left column.
In the Outbound relay section, select Allow users to send mail through an external SMTP when configuring a "from" address hosted
outside your domain.
Click Save changes.
They also provided a help link: http://support.google.com/a/bin/answer.py?hl=en&answer=176054
After turning on Outbound relay and using the proxy to login to the webmail one more time (thanks to #DaniloBargen and #joshcartme) the issue was resolved. I've read the link explaining what the Outbound relay is and I'm not really sure why would I need it (I don't believe I'm using an external SMTP server).
Since I'm not really sure this is what solved the issue I won't mark the response as accepted until I get some confirmation.
Set up an ssh tunnel to the server in question so that you could, from your home computer, log in to the gmail web client using the server's IP. You probably need to tunnel port 80 and port 443, maybe just 443. After logging in through the web client the problem should go away according to knowledge base article listed in the SMTPAuthenticationError.
Here's an example of how to set up the tunnel:
http://www.noah.org/wiki/SSH_tunnel#simple_port_forwarding_.28SSH_tunneling.29
Option #1 (this worked for me):
After getting the error Please log in with your web browser and then try again. Learn more etc. when trying to send email from my web application, I logged in to the email via browser from my local computer.
After I logged in, there was a yellow notification bar on top which asking me if I want to allow external application access my mail. I confirmed this and Google asked me to log in to the account from the application within the next 10 mins. This will white-list the application.
Option #2:
If Option #1doesn't work for you, try this: http://www.rocketideas.com/2012/05/gmail-error-password-not-accepted-from-server-solved/
etusm provided two locations to turn on less secure apps:
One here: https://myaccount.google.com/security?pli=1#connectedapps
(bottom of the page)
And one here: https://www.google.com/settings/security/lesssecureapps
both were turned on, but my headless server still couldn't send me an email. based on JohnPang's google+ recommendation, i found a third location where i had to allow access to less secure apps:
in myaccount.google.com, under 'Sign-in & Security', select 'Connected apps & sites'. this also has an option to 'Allow less secure apps'. after turning this one on, my server could now send me an automated email.
I found the solution at: https://support.google.com/accounts/answer/185833?hl=en and finally https://security.google.com/settings/security/apppasswords
If you are testing your project on a local machine, you should go to the latter link, and enable "Access for less secure apps".
Do you have two factor authentication enabled for the apps account ? Then you might need to use an application specific password for that application.
All of the above doesn't help in my case (weird). But this link might help you:
https://security.google.com/settings/security/activity
You can access it via Google Plus
Open Google+
Select "Security" from the top
Under "Recent activity" click "View all events"
You will see a list of "Unusual Activity"
It shows "Application / device sign-in attempt (prevented) Singapore" as I'm using AWS from Singapore
Click on "Change" > "Yes, that was me!"
Retry again. Done!
As of now (look at my post date) there is only one "Allow less secure apps" toggle in the Gmail account admin UI:
https://myaccount.google.com/u/0/security#connectedapps
It'll work from your local computer (Mac or PC) after that.
To allow access from Amazon EC2 (and I suspect other Cloud-located hosts), there is yet another flag to set in Google's never ending battle with spammers:
https://accounts.google.com/b/0/DisplayUnlockCaptcha
Recently, I have found that this issue can be resolved by confirming that the activity has originated from a request I initiated, by visiting Google Account
I had to confirm, under Security Events, that the suspicious activity was in-fact me, even though the originating server from where the request came from was cloud hosted, and therefore over 1000 km away. After clicking this step, and setting less secure apps, I was able to use getmail to retrieve my mail, over ssl using either imap or pop.
Just want to highlight Danilo Bargen's comment:
An easier way to connect to the other network using tunnels is to use a dynamic tunnel (ssh -D 6789 remotehost) and then to set localhost:6789 as SOCKS5-Proxy in Firefox. Then you are basically in the remote network with your browser and localhost is the remote host
Also I want to add that SOCKS Proxy method also works with Chrome. As a result you can log in with your local web browser as if you are on a server.
change your settings at https://www.google.com/settings/security/lesssecureapps so that your account is no longer protected by modern security standards.
This is occuring due to some apps are marked as less secure apps by google. So to use those apps, you need to give access for those apps. to do that follow http://www.codematrics.com/your-imap-server-wants-to-alert-you-to-the-following-please-login-via-your-web-browser-gmail/
Hope this will solve your issue.
In my case, when i tried to login to the google account via web, it asked me for a captcha. I entered the captcha and then the automation worked.