Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I have been successfully developing Facebook Messenger bots for the past couple months and lately have been experiencing an issue where 'postbacks' are sometimes not sent to my server, even though plain typed messages are sent immediately and of course web hooks validate fine.
Sometimes with enough teardown/subscribing of web hooks and pages the postbacks work again but I can't always get it to work again. I have multiple bots and multiple pages running not sure if that is related.
Also, yes I'm currently subscribed to receive postbacks.
Has anyone else experienced this? Thank you
It may have been resolved by now, but i was finally able to figure out when does postback work, and when it does not.
As per my observation, and many tests I came to conclusion, that facebook uses the same access token to "postback" which is used to create the persistant menu, generic template button, or a button template.
If the page Id, or the APP id (which is more probable, as people have a prod and test app for the same bot) differs, the postbacks are not sent back to webhook even though the webhook has the "messaging_postbacks" subscribed.
In my case it turned out the the page access token was generated with the production APP id, and i was testing in my test app, which had different app iD. Also, my persistent menu also worked when generated thru a test app access_token.
As a best practice, i hard code the access token (safer as well, as the generated access_tokens expires in some time) if the environment is not prod, and use the logic to generate the token when the app is live.
Update:
So it turns out after 44 hours of firefighting, the problem auto-corrected itself. Facebook team replied that all they have is a 502 error. and that too resolved automatically. I have contacted my domain provider and AWS and they said that that the issue is not at their end.
My conclusion, something must be happening in facebook's infrastructure as the same domain cannot have partial 502 errors (meaning for one use case it happens and other it doesn't when the webhook url is same). Hopefully, they figure it out even though they don't tell us.
So I don't have any reputation points for commenting so I am posting as an answer. I am facing a similar issue, the only difference is we are getting a quick response in postbacks but not messages.
We are consistently facing a problem of irregular incoming messages on our server for messenger bot. Our observation is that we receive a payload only after a few (random) seconds after the message has been typed (and sent) by the user. However, facebook instantaneously sends us the necessary payload if a buttontap is performed.
We have established that the apache server is not receiving any request (during that time). We have also established that our SSL certificate is not expired. Moreover, we have all the necessary ports open on our AWS instance (mainly 443 and 80).
Any clues anyone? we are facing this issue for last 21-22 hours.
I got the same problem yesterday, while developing the second facebook messenger bot (for the second Page). The postback wont come after some hours, that's what ridiculous (as I expected, the messages shouldn't come!!!).
The reason was the Page Access Token for the second Page was wrong! You have to pick the right Token from the right App. Because it's possible to generate the Page Access Token for the second Page from the first App.
While subscribing to webhook select messaging_postbacks checkbox.
Related
I want log all the client side errors in a centralised logging file .Can anyone tell me how to do this in react.(Client side error logging).I am not able to find support for this in react.Can anyone tell how to implement it by a small demo
As others have commented on, React runs in the browser and on the client side, so writing files is not possible.
However, I was searching myself for centralised logging for a frontend application and came across this post. Perhaps the question is not asked correctly, but basically I wanted to log and report crashes in the frontend to a central place or dashboard. When the app users run into issues, I at least know by seeing these errors in the dashboard. I found a few websites / services that can do this for you.
First tear is a free subscription
Rollbar
Sentry
LogRocket
Bugsnag
ClickUp
First tear is paid
Instabug
Raygun
Dynatrace
I've used this list myself to do some research and thought to share it here for anyone else who might currently be in my position. Perhaps it will help you along and you find it useful. Examples of how to implement them are in the docs. See which solution works best for you.
I'm still very new to React so forgive me if the question is too naive. To my understand, React usually requires an API to do XHR requests. So someone with very basic tech background can easily figure out what the api looks like by looking at the network tab in web browser's debug console.
For example, people might find a page that calls to api https://www.example.com/product/1, then they can just do brute force scraping on product id 1 - 10000 to get data for all products.
https://www.example.com/api/v1/product/1
https://www.example.com/api/v1/product/2
https://www.example.com/api/v1/product/3
https://www.example.com/api/v1/product/4
https://www.example.com/api/v1/product/5
https://www.example.com/api/v1/product/6
...
Even with user auth, one can just use same cookie or token when they login to make the call and get the data.
So what is the best way to prevent scraping on React app? or maybe the api shouldn't be designed as such, hence I'm just asking the wrong question?
Here are some suggestions to address the issue you're facing:
This is a common problem. You need to solve it by using id's that are GUID's and not sequentially generated integers.
Restricting to the same-origin won't work because someone can make a request through Postman or Insomnia or Curl.
You can also introduce rate-limiting
In addition, you can invalidate your token after a certain number of requests or require it to be renewed after every 10 requests
I think no matter what you do to the JavaScript code, reading your API endpoint is the easiest thing in the world(Wireshark is an easy, bad example), once it is called upon from the browser. Expect it to be public, with that said, protecting it it is easier than you might anticipate.
Access-Control-Allow-Origin is your friend
Only allow requests to come from given urls. This may or may not allow GET requests but it will always allow direct access on GET routes. Keep that in mind.
PHP Example
$origin = $_SERVER['HTTP_ORIGIN'];
$allowed_domains = [
'http://mysite1.com',
'https://www.mysite2.com',
'http://www.mysite2.com',
];
if (in_array($origin, $allowed_domains)) {
header('Access-Control-Allow-Origin: ' . $origin);
}
Use some form of token that can be validated
This is another conventional approach, and you can find more about this here: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
Cheers!
The specific action we are trying to performe is to create a charge request with Stripe:
Charge charge = Charge.create(params);
Using Stripe's Java implementation (version 5.35.1) we encounter a APIConnectionException when running the application on the deployed App Engine server. Interestingly, the issue does not occur using App Engine's local dev server.
We contacted Stripe and they said everything is fine on their side. They explained that "this error indicates that your server is not able to contact our API and that it ends up timing out waiting for an answer. Usually, this is due to something misconfigured on your server such as a DNS not redirecting to Stripe properly."
We were wondering if there are some configuration settings on App Engine which cause the problem. However, since there is no specific error message we cound not figure out what might cause the connection problem.
Similar problems which did not provide enough help to resolve this issue: https://issuetracker.google.com/35901039
Thanks for your help!
The problem seems to have solved itself. It occured for a couple of days and since a few hours the exact same code is working fine. Just like in https://issuetracker.google.com/issues/35901039 the problem is suddenly gone for some reason.
UPDATE: Please, if anyone can help: Google is waiting for inputs and examples of this problem on their bug tracking tool. If you have reproducible steps for this issue, please share them on: https://code.google.com/p/googleappengine/issues/detail?id=10937
I'm trying to fetch data from the StackExchange API using a Google App Engine backend. As you may know, some of StackExchange's APIs are site-specific, requiring developers to run queries against every site the user is registered in.
So, here's my backend code for fetching timeline data from these sites. The feed_info_site variable holds the StackExchange site name (such as 'security', 'serverfault', etc.).
data = json.loads(urllib.urlopen("%sme/timeline?%s" %
(self.API_BASE_URL, urllib.urlencode({"pagesize": 100,
"fromdate": se_since_timestamp, "filter": "!9WWBR
(nmw", "site": feed_info_site, "access_token":
decrypt(self.API_ACCESS_TOKEN_SECRET, self.access_token), "key":
self.API_APP_KEY}))).read())
for item in data['items']:
... # code for parsing timeline items
When running this query on all sites except Stack Overflow, everything works OK. What's weird is, when the feed_info_site variable is set to 'stackoverflow', I get the following error from Google App Engine:
HTTPException: Invalid and/or missing SSL certificate for URL:
https://api.stackexchange.com/2.2/me/timeline?
filter=%219WWBR%28nmw&access_token=
<ACCESS_TOKEN_REMOVED>&fromdate=1&pagesize=100&key=
<API_KEY_REMOVED>&site=stackoverflow
Of course, if I run the same query in Safari, I get the JSON results I'm expecting from the API. So the problem really lies in Google's URLfetch service. I found several topics here on Stack Overflow related to similar HTTPS/SSL exceptions, but no accepted answer solved my problems. I tried removing cacerts.txt files. I also tried making the call with validate_certificate=False, with no success.
I think the problem is not strictly related to HTTPS/SSL. If so, how would you explain that changing a single API parameter would make the request to fail?
Wait for the next update to the app engine (scheduled one soon) then update.
Replace browserid.org/verify with another service (verifier.loogin.persona.org/verify is a good service hosted by Mozilla what could be used)
Make sure cacerts.txt doesnt exist (looks like you have sorted but just in-case :-) )
Attempt again
Good luck!
-Brendan
I was facing the same error, google has updated the app engine now, error resolved, please check the updated docs.
I have implemented Google App Engine's Channel API feature in my application. Everything runs smoothly. I create new channels every one hour for every user. I have managed to maintain one channel per session (same channel for different tabs in a browser). I have implemented the onerror and onclose methods in such a way that every time they are invoked, a call is made to the server requesting for a valid token.
Sometimes, after the channel's been alive for a while, it gets disconnected. I can see failed HTTP calls to talkgadget.google.com on the JavaScript console. The URLs are something like this:
https://129.talkgadget.google.com/talkgadget/dch/bind?VER=8&clid=.....
These calls have responses like "401 (Token timed out)" or "401 (Token invalid)".
Which is indeed true, the token used by the client is invalid. It should get updated with the new token but the onerror or onclose methods aren't invoked. How am I supposed to figure out when this would happen or how to handle it? There is no real way to say if a client is disconnected or not except for the onerror or onclose methods. This issue is resolved if I refresh the page (I get the valid token from database every time the user refreshes).
I checked the socket objects's "readyState" property and it had the value 1. There are many who face this issue and as of date, there seems to be no valid solution offered by the folks at GAE.
Edit: I'm a premium account holder and this issue is holding back our deployments.
Edit 2: Having one channel per tab reduces the frequency of this happening. But it doesn't solve the problem completely.
It has been six days since I posted the question and there has been no response from the AppEngine team or any other users.
The workaround I applied was to have a button on the site that would fetch the (valid) token from the database, close the channel and then open it again with the token received.
Sometimes its a new token which should've been received before, sometimes its the same token that had been valid all along.
This issue cannot be replicated often I agree, but when it happens, it causes a lot of damage. I hope I find a solution soon.
Edit: Having one channel per tab reduces the frequency of this happening. But it doesn't solve the problem completely.