We have a google group setup to handle inbound support emails. We have mailgun setup to forward from various addr#ourdomain.com inboxes to that group. This worked fine up until recently. Now mailgun claims the delivery worked - but nothing shows up in the google group. Here is the mailgun detailed status of the message ...
"event": "delivered",
"delivery-status": {
"tls": true,
"mx-host": "aspmx.l.google.com",
"code": 250,
"description": "",
"session-seconds": 0.647407054901123,
"utf8": true,
"attempt-no": 1,
"message": "OK",
"certificate-verified": true
}
I don't know what else to do in order to debug this - and determine where the email is going # google?
Turns out this was tied to either a new or newly-changed setting in the google group whereby all new messages were going into a pending folder to be reviewed by a group moderator (this had not previously been the case). Changing that setting to bypass the pending folder and deliver straight to the group resolved the problem.
Related
I am working with Firebase Cloud Messaging in Django using django-push-notifications to deliver push notifications to our users via desktop notifications.
After a browser is fully closed (such as when the the computer is turned off), our users receive a backlog of all notifications previously sent next time they boot up.
While there are situations where a user would want to receive the entire backlog of messages, this is not one of them.
It seems the answer is to set TTL=0, as per this section of the FCM documentation, but my attempts are not resulting in the desired behavior.
Please help me better understand TTL in this context. If TTL is the right way to go, what is the proper way to format TTL in send_message() using django-push-notifications so that messages will not accumulate if not immediately delivered?
Here is what I have attempted:
devices.send_message(
body,
TTL=0,
time_to_live=0,
link='blah',
extra={'title': 'blah blah', 'icon': '/foo/bar.png'}
)
The format that you send seems different from the one in the documentation you linked. From the documentation:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}
So key here is that the time-to-live for a webpush message is set under webpush/headers/TTL, while you're adding it to the top-level.
Based on Stackdriver, I want to send notifications to my Centreon monitoring (behind Nagios) for workflow reasons, do you have any idea on how to do so?
Thank you
Stackdriver alerting allows webhook notifications, so you can run a server to forward the notifications anywhere you need to (including Centreon), and point the Stackdriver alerting notification channel to that server.
There are two ways to send external information in the Centreon queue without a traditional passive agent mode.
First, you can use the Centreon DSM (Dynamic Services Management) addon.
It is interesting because you don't have to register a dedicated and already known service in your configuration to match the notification.
With Centreon DSM, Centreon can receive events such as SNMP traps resulting from the detection of a problem and assign the event dynamically to a slot defined in Centreon, like a tray event.
A resource has a set number of “slots” on which alerts will be assigned (stored). While this event has not been taken into account by human action, it will remain visible in the Centreon web frontend. When the event is acknowledged, the slot becomes available for new events.
The event must be transmitted to the server via an SNMP Trap.
All the configuration is made through Centreon web interface after the module installation.
Complete explanations, screenshots, and tips are described on the online documentation: https://documentation.centreon.com/docs/centreon-dsm/en/latest/user.html
Secondly, Centreon developers added a Centreon REST API you can use to submit information to the monitoring engine.
This feature is easier to use than the SNMP Trap way.
In that case, you have to create both host/service objects before any API utilization.
To send status, please use the following URL using POST method:
api.domain.tld/centreon/api/index.php?action=submit&object=centreon_submit_results
Header
key value
Content-Type application/json
centreon-auth-token the value of authToken you got on the authentication response
Example of service body submit: The body is a JSON with the parameters provided above formatted as below:
{
"results": [
{
"updatetime": "1528884076",
"host": "Centreon-Central"
"service": "Memory",
"status": "2"
"output": "The service is in CRITICAL state"
"perfdata": "perf=20"
},
{
"updatetime": "1528884076",
"host": "Centreon-Central"
"service": "fake-service",
"status": "1"
"output": "The service is in WARNING state"
"perfdata": "perf=10"
}
]
}
Example of body response: :: The response body is a JSON with the HTTP return code, and a message for each submit:
{
"results": [
{
"code": 202,
"message": "The status send to the engine"
},
{
"code": 404,
"message": "The service is not present."
}
]
}
More information is available in the online documentation: https://documentation.centreon.com/docs/centreon/en/19.04/api/api_rest/index.html
Centreon REST API also allows to get real-time status for hosts, services and do the object configuration.
I noticed a strange charge for SMS messages being sent a few months back and since our code doesn't yet support sending SMS messages, I have been investigating it.
It turns out AWS Cognito is sending text messages when we call "UpdateUserPool" to +12064350128 (206-435-0128). This is not a phone number associated with our account, in our code, or with any of our personnel. What's worse is that this AWS account hosts only development environments where the public doesn't have access. So we know it's either an Amazon employee's number or a security leak (or both).
Has anybody else had this happen? A google for that phone number turned up nothing, other than it is probably from somebody in Seattle.
Does anybody know what kind of data is being sent in these messages or how to figure out what's in them? Is it passwords & confidential info?
I turned on SMS logging and this is all of the data I could gather:
{
"notification": {
"messageId": "975e37a9-a5f1-5397-b6d0-63fdbad40d83",
"timestamp": "2018-10-31 21:21:41.756"
},
"delivery": {
"destination": "+12064350128",
"priceInUSD": 0.00645,
"smsType": "Transactional",
"providerResponse": "Message has been accepted by phone",
"dwellTimeMs": 168,
"dwellTimeMsUntilDeviceAck": 2514670
},
"status": "SUCCESS"
}
I received the following from AWS support. Looks like it's innocuous. Whew!
I completely understand your concern of AWS Cognito sending messages
to phone number +12064350128. I got in touch with the Cognito team and
found that it is an expected behaviour that when you make an
UpdateUserPool API call, a message is sent out to +12064350128 and
this applies to all AWS accounts. The phone number +12064350128 is an
internal number and a message to this number is sent out to verify if
Cognito and SNS are integrated correctly so that Cognito can send SMS
to other numbers. Please note that no security information including
passwords is being passed in the content of this SMS message, It's
just a sample message indicating SNS is integrated with Cognito
correctly.
Please be rest assured that we treat customer's data with utmost
privacy and we have a strict security mechanism in place to check any
fraudulent activities.
I also completely agree that the above behavior needs to be documented
and hence I will be reaching out to the Cognito team to get this
updated in our docs to avoid further confusion.
As part of some testing that I was doing, I replied STOP to an SMS message that was sent via Amazon's Pinpoint service. I received the acknowledgement that I had been removed from further notifications.
I want to opt back in to receiving those messages, but I can't figure out how to do that. I looked at the Pinpoint documentation and I did not see a way to do it. I looked in the Amazon Pinpoint Console and I did not see a way to remove a number from the blacklist. I have tried the standard terms that other SMS providers use such as UNSTOP, UNBLOCK, and START, but none of those work either. Does anyone have any suggestions. I do not want to contact Amazon support about this unless I have to.
As described here: https://docs.aws.amazon.com/cli/latest/reference/sns/opt-in-phone-number.html
aws sns opt-in-phone-number --phone-number ###-###-####
You can also use AWS Console -> Amazon SNS -> Mobile -> Text Messaging(SMS) section to see a list of opt-out phone numbers that was done through Pinpoint and choose to opt-in these numbers...
AWS Pinpoint has not come up with the APIs to check if the number is opted out or not. You can use the AWS SNS APIs for checking this as well for marking a mobile number as active again.
I've been trying to figure this out as well and I think I have a solution from a set of documentation I found about setting up Pinpoint. Below is python pseudocode; from my understanding we just have to update the "OptOut" status for the endpoint (i.e. the phone number that originally opted out).
# Python pseudo code with comments
import boto 3
import datetime
pinpoint = boto3.Session(**login_kwargs).client("pinpoint")
opt_in_response = pinpoint.update_endpoint(
ApplicationId="<App ID from your project>",
EndpointId="<Endpoint you are updating>", # Same as your phone number?
EndpointRequest={
"Address": "<Phone you are updating>",
"ChannelType": 'SMS',
"OptOut": "NONE", # Change from "ALL" (which is opt-out) to "NONE", opt-in
"EffectiveDate": datetime.datetime.utcnow().isoformat(),
"Attributes": {
"OptInTimestamp": [datetime.datetime.utcnow().isoformat()]
}
}
)
I attempted to follow this documentation https://docs.aws.amazon.com/pinpoint/latest/developerguide/pinpoint-dg.pdf (the relevant stuff starts on page 92), which happens to not be in Python.
I wasn't successful but I'm pretty sure this is how you should be able to opt back in (if anyone who knows node.js can verify this solution that'd be awesome).
In AWS API Gateway, I have a GET method that invokes a lambda function.
When I test the method in the API Gateway dashboard, the lambda function executes successfully but API Gateway is not mapping the context.success() call to a 200 result despite having default mapping set to yes.
Instead I get this error:
Execution failed due to configuration error: No match for output mapping and no default output mapping configured
This is my Integration Response setup:
And this is my method response setup:
Basically I would expect the API Gateway to recognize the successful lambda execution and then map it by default to a 200 response but
that doesn't happen.
Does anyone know why this isn't working?
I have same issue while uploading api using serverless framework. You can simply follow bellow steps which resolve my issue.
1- Navigate to aws api gateway
2- find your api and click on method(Post, Get, Any, etc)
3- click on method response
4- Add method with 200 response.
5- Save it & test
I had the similar issue, got it resolved by adding the method response 200
This is a 'check-the-basics' type of answer. In my scenario, CORS and the bug mentioned above were not at issue. However, the error message given in the title is exactly what I saw and what led me to this thread.
Instead, (an an API Gateway newb) I had failed to redeploy the deployment. Once I did that, everything worked.
As a bonus, for Terraform 0.12 users, the magic you need and should use is a triggers parameter for your aws_api_gateway_deployment resource. This will automatically redeploy for you when other related APIGW resources change. See the TF documentation for details.
There was an issue when saving the default integration response mapping which has been resolved. The bug caused requests to API methods that were saved incorrectly to return a 500 error, the CloudWatch logs should contain:
Execution failed due to configuration error:
No match for output mapping and no default output mapping configured.
Since the 'ENABLE CORS' saves the default integration response, this issue also appeared in your scenario.
For more information, please refer to the AWS forums entry: https://forums.aws.amazon.com/thread.jspa?threadID=221197&tstart=0
Best,
Jurgen
What worked for me:
1. In Api Gateway Console created OPTIONS method manually
2. In the Method Response section under created OPTIONS method added 200 OK
3. Selected Option method and enabled CORS from menu
I found the problem:
Amazon had added a new button in the API-Gateway resource configuration
titled 'Enable CORS'. I had earlier clicked this however once enabled
there doesn't seem to be a way to disable it
Enabling CORS using this button (Instead of doing it manually which is what I ended up doing) seems to cause an internal server error even on a
successful lambda execution.
SOLUTION: I deleted the resource and created it again without clicking
on 'Enable CORS' this time and everything worked fine.
This seems to be a BUG with that feature but perhaps I just don't
understand it well enough. Comment if you have any further information.
Thanks.
Check the box which says "Use Lambda Proxy integration".
This works fine for me. For reference, my lambda function looks like this...
def lambda_handler(event, context:
# Get params
param1 = event['queryStringParameters']['param1']
param2 = event['queryStringParameters']['param2']
# Do some stuff with params to get body
body = some_fn(param1, param2)
# Return response object
response_object = {}
response_object['statusCode'] = 200
response_object['headers'] = {}
response_object['headers']['Content-Type']='application/json'
response_object['body'] = json.dumps(body)
return response_object
I just drop this here because I faced the same issue today and in my case was that we are appending at the end of the endpoint a /. So for example, if this is the definition:
{
"openapi": "3.0.1",
"info": {
"title": "some api",
"version": "2021-04-23T23:59:37Z"
},
"servers": [
{
"url": "https://api-gw.domain.com"
}
],
"paths": {
"/api/{version}/intelligence/topic": {
"get": {
"parameters": [
{
"name": "username",
"in": "query",
"required": true,
"schema": {
"type": "string"
}
},
{
"name": "version",
"in": "path",
"required": true,
"schema": {
"type": "string"
}
},
{
"name": "x-api-key",
"in": "header",
"required": true,
"schema": {
"type": "string"
}
},
{
"name": "X-AWS-Cognito-Group-ID",
"in": "header",
"schema": {
"type": "string"
}
}
],
...
Remove any / at the end of the endpoint: /api/{version}/intelligence/topic. Also do the same in uri on apigateway-integration section of the swagger + api gw extensions json.
Make sure your ARN for the role is indeed a role (and not, e.g., the policy).