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.
Related
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.
I am using asmack on Android to talk to Facebook XMPP.
When an incoming message arrives, I get the (XMPP) thread ID from that message/chat. Sending further messages (using that ID) works just fine.
The problem starts when the first message is sent from my application's side. Then I don't have the current thread ID (since they change on the Facebook server). And sending the message does not work. My system sends OK, but it is never registered on Facebook.
So, how do I get the initial (XMPP) thread ID from an inbox chat?
I tried using the graph API to send a message (inbox/comment). But it does not work (you have to be whitelisted... whatever it is).
Please help, how can I initiate an XMPP thread, and not just respond?
Study the one of open source project which used Asmack then you will be get clear idea how its working. Beem-Project is one one of open course project which used Asmack
It turns out that Facebook will accept any thread ID you give it. There was a problem in the way I handled new message threads created locally, rather then external created threads (from Facebook). Now everything works, even firing up a thread from my application, using asmack.
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:
Ok .. I am using the Dialog JS API to send requests to people. I know this is working because
The JavaScript callback shows the request ID
On the recipient's account, the "App Requests" item on the left side bar has a count which is increasing with each and every request that gets sent
What I cannot figure out is why, although the requests are being sent and the counts are increasing, there is nothing that indicates that a request has in fact been sent.
I have checked the Notifications section and it is empty. I have also checked the following two URLs, both showing nothing:
http://www.facebook.com/reqs.php
http://www.facebook.com/reqs.php#!/?sk=apps
After hours of debugging and looking at other peoples apps, I started digging into Facebook's bug tracker and found someone else with the same problem today Apparently there are a number of "request" bugs today.
https://developers.facebook.com/bugs/237217296327314
Do you have a valid canvas url and valid secure canvas url in your facebook app settings? May be something to check as I believe it is required.
I am getting the response as below.
{"status":21002, "exception":"java.lang.NullPointerException"}
I am encoding the receipt using Base64 only.
I am testing it in sandbox.
What will be the problem? Can anyone help me?
hi all i got the solution
just send the receipt data after encoding into base 64 as json with key "receipt-data"
VIP Worth noting that 21002 is also the message you get back when trying to verify a transaction that was initiated via rooted iTunes hack software like the Urus app.
We verify all transactions server side, so are not device dependant, the only transactions that get the 21002 response are ALL not real payments.
an easy way to spot it to look at the transaction id returned Urus gives com.urus.iap.XXXXXXX (x being random numbers), other ones include returning the pack name as the completed transaction id, all very different to the id's you get from the various iTunes servers.
I can't recommend more that everyone verifies server-side in an environment you can control, test and prove, that cant be manipulated (unless your hacked). If this is not an option, then do not pay out on a 21002 response.
verifying in a java environment the json response for the 21002 will be:
json: {"status":21002,"exception":"java.lang.ClassCastException"}
We had the same problem - until we discovered that we didn't include the post body in the request and only sent an empty request.
The only option that work for me after 2 days of hitting my head against the wall:
Testing in the sandbox
Pay attention to this advice by apple
"Important Do not sign in with your test account in the Settings application."
Make sure on the test device you are signed out of the "test" apple store account before encoding to base 64.