After weeks of having a WhatsApp Cloud API up and running, suddenly all my phone numbers can no longer send messages. Keep getting (#200) You do not have the necessary permissions required to send messages on behalf of this WhatsApp Business Account.
I have already checked the Meta Token Debugger, and my token has all necessary permissions (whatsapp_business_management and whatsapp_business_messaging (and business_management just in case)), and have added (and re-added) (system)users to my WhatsApp accounts w/ new tokens, but no luck.
I already have a support case with Meta, but so far they've been radio-silent, and it's kinda business critical to make sure my bots are able to reply to any request, so trying here too.
Related
I have created an app in Django. Using Twilio Verify API (free trial) for OTP.
Problem:-
It's working fine but when a user try to get the OTP multiple times, Twilio creates an exception "HTTP 429 error: Unable to create record: Too many requests". After this I was not able to use this for the whole day even for different mobile number or device.
How to bypass this issue and precisely what is the reason behind this issue?
Twilio Developer Evangelist here. The Verify API has rate limits for sending SMS codes to the same phone number, ~5 requests within 10 minutes. I'm not sure why it wasn't working with a different phone number, though - let me know if you're still having issues after you try the below.
You're definitely not the first person to run into this issue, so I have a blog post that should answer the question: How to test Twilio Verify without getting rate limited
tl;dr your options include -
Complete a verification lifecycle by calling the Verification Check endpoint
Wait for the verification to expire (in 10 minutes)
I also recommend spinning up a Verification Testing Dashboard that will help you check/cancel a verification during development.
Here's another blog post about managing retry logic that's also designed to prevent hitting API rate limits: https://www.twilio.com/blog/best-practices-retry-logic-sms-2fa
This may have been solved by now but for anyone else it's possible that the free Twilio trial account has expired or used up it's allocated requests. This happened me as I had forgotten I was using a trial account in a test environment, and when tests started to fail this was the issue.
I encountered the same problem with email channel when a user tries to send verify api multiple times and gets this error. All other emails would get the same error, and nobody can get verified. This looks to me that one user gets rate limited and it could affect all other users.
Last year I was building an application to create my own YT dashboard.
It was based only the code of a tutorial
They basically authenticate a user via OAuth and send requests to get channel data or playlists of the authenticated user.
I was trying out both the original tutorial app and my own (after a few dormant months) and they suddenly don't work anymore.
Meaning: I can authenticate on both, but on the original version I get a 403 error telling me: "The request is missing a valid API key." (on requesting channel data)
This is confusing because the API key is never used because only the OAuth client id was necessary.
And on my own fancy version, I get a 403 error telling me that I've exceeded my getting started quota. (on requesting the users playlists)
Looking at my quota page:
I can see, that queries per day (why is it there twice?) is somehow set to 0.
Perhaps creating a new OAuth 2.0 Client ID or a new API key would solve these errors, as was suggested in another post.
But since I'm planning to use the YT Data API in a real project soon and want to prevent this from ever happening I would like to understand what was going on. Why the daily quota limit is suddenly turned to 0 and how to go about it when that happens.
Or at least how to contact google about it.
Perhaps some of you have some insights.
UPDATE:
I've just found this post reporting, that after 90 inactive days, the quota is automatically set to 0.
Now I created a new OAuth Client Id and replaced the constant in my code. Nothing changed so far. Perhaps I have to wait 24h. Or perhaps I have to fill out this form which apparently can lead to months of back and forth email nonsense. I sure hope not.
It seemed the only viable option was to create a new project with new credentials.
(And one should not forget that the YT Data API has to be enabled again for the new project.)
I'm trying to get some basic analytics for a Cognito user pool. It seemed simple enough to do, I created a project in Pinpoint, then I went to my user pool, went to General settings > Analytics, clicked the Add Analytics button, choose the Amazon Cognito app client that my app uses, pointed to the Pinpoint project I just created, checked the "Share user profile data" checkbox (though I assume that's not absolutely necessary), and it had the message telling me if would use the IAM role and so on. Clicked Save, got no error, I assumed at this point I would start seeing Analytics in Pinpoint, but there's absolutely nothing showing up.I do have a message saying I haven't enabled any features yet, but I don't see any features I'd need to enable. I don't care about the campaigns as of now, and then under Application analytics it seems geared to you manually updating your mobile or web app to send something, but I thought that was if you need to customize something. Am I mistaken? Will this integration only work if you change your web app to explicitly send things to Pinpoint? I just assumed if I connected Cognito and Pinpoint the analytics would show since Cognito obviously knows people are logging in without you needing to manually make some extra request.
From my research, I found out that since you are using a Web Application without using AWS Amplify framework, you need to add additional lines of code to your application in order to send Cognito authentication analytics data to your Amazon Pinpoint project.
If you are using the Javascript SDK you may add the initate-Auth property code snippet to your front-end application:
var cognitoidentityserviceprovider = new AWS.CognitoIdentityServiceProvider();
var params = {
AuthFlow: "USER_PASSWORD_AUTH",
ClientId: 'STRING_VALUE', /* the client ID attached to the Pinpoint project */
AuthParameters: {
'USERNAME': 'STRING_VALUE',
'PASSWORD': 'STRING_VALUE'
},
AnalyticsMetadata: {
AnalyticsEndpointId: 'STRING_VALUE' /* the Pinpoint project ID */
},
};
cognitoidentityserviceprovider.initiateAuth(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});
In the above code snippet, the Pinpoint project/application ID is added as part of the "AnalyticsMetadata" parameter when the client makes the API calls (e.g. sign-in, sign-up, etc.) to the Cognito user pool. Therefore, the API calls will have the pinpoint project ID attached to them and Cognito can use that information to send the data to your Pinpoint project. Without this crucial step, analytics data will not be sent to Pinpoint and will result in the behavior you have described.
If using CLI (for verification/testing purpose), you may execute the following AWS CLI initiate-auth command below :
$ aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --auth-parameters USERNAME=STRING_VALUE,PASSWORD=STRING_VALUE --client-id STRING_VALUE --analytics-metadata AnalyticsEndpointId=STRING_VALUE
The take away point is that :
Amazon Cognito integration with Amazon Pinpoint only works for apps (clients) that are using Cognito SDK for Mobile Apps (AWS Mobile SDKs or JavaScript - AWS Amplify JavaScript library).
Just a note to syumaK's response, yes you need to update your code's initAuth call to include the AnalyticsMetadat property. However, I found out that the AnalyticsEndpointId should NOT be the Pinpoint project ID.
I believe that since you've configured Cognito already to integrate with the pinpoint project, it knows which pinpoint project you are sending metrics to already. The AnalyticsEndpointId should be a uniquely identifier for the login.
The documentation is definitely flaky here. The cli one from syumaK's seems to describe it differently than Cognito API Reference
What happened to me was that I used the pinpoint project id, and when I log in with multiple users, it thinks it's the same one. The daily active users remains at one. AWS Support clarified that it should be a unique identifier for each user. So after changing the id to be the user's email, I am starting to get accurate numbers for the daily active users.
It also seems like this is just about as useful as it is going to be for not using the Cognito SDK for Mobile Apps or Amplify. You can only get information like daily/monthly active users, authentication metrics. You don't have the ability to further break down by segments, etc.
My team is about to start a new project, they want to use AWS Cognito for handling authentication and authorization. After doing some research, I decided to use Amplify Javascript to build a login page with Angular. (this link: https://aws-amplify.github.io/docs/js/angular)
The Sign in and Sign up page work quite well but my team concern about the idea that my application sends the login information (username, password...) directly to AWS Cognito service. They think that there might be some risk of exposing the response from AWS Cognito to the client, so they recommend me to create a Nodejs server to forward the login request to Cognito and return only the JwtToken back to the client.
Even their idea sound pretty reasonable, the fact that there is no warning on the Amplify website also concerns me.
So here the question, is there any problem with sending the login information directly to Cognito?
I don't see any risk of sending the login request directly to aws Cognito service, by adding a node js server you're increasing the network nodes where the login details to pass which is I believe riskier from design model.
That's the reason why payment processors preferred to have credit card details sent directly.
however one thing I'd recommend is to host the login under iframe which make it immune from external js interference, and upon getting the login response details you can pass it to the nodejs server.
I'm banging my head against the wall trying to get an AWS Lex based chatbot integrated with Facebook.
As far as I can tell, everything is set up correctly.
When I send a message to my page in Facebook, I don't get a reply. However, the analytics in my app shows that the app is getting messages, so I know the message is making it from the page to the app.
When I try to hit the AWS Lex Webhook directly using POSTMAN, the webhook responds to literally everything I sent to it with a blank HTTP 200 OK response.
The lambda function that is tied to the AWS Lex chatbot is not getting invoked as a result of the messages from Facebook because no logs are getting generated and cloudwatch doesn't show an attempts to run the lambda function.
Does anyone have any ideas?
UPDATE : I ended up engineering around this by bypassing the Facebook channel capability inside AWS Lex and using Lambda instead. I deployed a passthrough API which calls a lambda function and then interacts with AWS Lex via Boto3/Python. In theory this is all supposed to be taken care of from inside AWS Lex with the Facebook channel integration, but I wasn't able to get it to work so I just built around it.
Verify Amazon lex is properly configured with facebook messenger .
Check : Page access token
Verification token
App ID
Check if your webhook is subscribed to page you are messaging on.
Check if your facebook user is added as tester/admin/developer
Check if your latest version of BOt is published on intended alias.
Also while configuring webhook tick necessary options : messages, messaging_postbacks, messaging_optins, message_deliveries, message_reads, messaging_payments
This should resolve your head ache. If not please reply