We have lot of applications created under Amazon AWS-SNS to send a push to apple devices.
While creating each app we are uploading p12 files, even every application's has p12 expiry date in the next year our applications getting expired(disabled), Due to this push is not going to endpoints which are saved under the same application.
Could any one please help me that what are the various reasons which caused Application ARN disabled? Thank you in advance.
sometimes the device token changes. Then, if you're trying to use an endpoint associated with a invalid token, SNS will disable it.
Even if you enable it again manually, SNS will be informed that this endpoint is no longer available and will disable it again.
This may help you:
Re-enabling an endpoint associated with an invalid token
When a mobile platform (such as APNS or GCM) informs SNS that the token used in the publish request was invalid, SNS disables the endpoint associated with that token. SNS will then reject subsequent publishes to that token. While it may be tempting to simply re-enable the endpoint and keep publishing, in most situations doing this has no beneficial effects: the messages published don’t get delivered and the endpoint becomes disabled again soon after.
The reason for this is that the token associated with the endpoint is genuinely invalid. Deliveries to it cannot succeed because it no longer corresponds to any installed app. The next time it is published to, the mobile platform will again inform SNS that the token is invalid, and SNS will again disable the endpoint.
To re-enable a disabled endpoint, it needs to be associated with a valid token (by using SetEndpointAttributes API call) and then enabled. Only then will deliveries to that endpoint become successful. The only time re-enabling an endpoint without updating its token will work is when a token associated with that endpoint used to be invalid but then became valid again. This can happen, for example, when an app was uninstalled and then re-installed on the same mobile device and received the same mobile token. The approach presented above does this, making sure to only re-enable an endpoint after verifying that the token associated with it is the most current one available.
You can read more here: Mobile token management with Amazon SNS
To avoid issues with .p12 certificates expiring, you may now use .p8 tokens for APNS in Amazon SNS. Check this out: https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-sns-token-authentication-api-mobile-notifications/
Related
I have an application (Java Spring backend + iOS/Android native frontends) that uses AWS Cognito for Authentication and AWS SNS for sending push notifications to devices. The client apps currently pass the device-specific push tokens (FCM, APNS) to the backend, which informs SNS.
We are struggling to figure out the best way to deal with users logging out or simply not using the mobile apps for a while, and expiring/disabling those push tokens. Cognito does not appear to have any sort of trigger or notification for when a token expires or a user signs out. This leads to users still receiving app pushes after logging out or when their access/refresh tokens have expired.
I am looking for suggestions and best practices on what to do here. Some options we entertained are to inform our backend in a separate call, move all device management there, or even façade all of Cognito behind our own backend calls, but maybe there’s better ways.
last month they released refresh token revocation, is a way to revoke a refresh token and all access tokens that were previously issued by that refresh token become invalid
this is enabled for new user pools but i believe in your case, you need to manually enable it in (e.g. you created the user pool before the feature was released)
Cognito does not appear to have any sort of trigger or notification for when a token expires or a user signs out.
you are correct here, but, in case you use GlobalSignOut API in your App, you could track it via CloudTrail or EventBridge and trigger a lambda do to something with the event
Some options we entertained are to inform our backend in a separate call, move all device management there, or even façade all of Cognito behind our own backend calls
i worked in both scenarios, while the façade gives a lot of flexibility, if you are offering social login, it is annoying to setup the whole oidc flow,
in my projects i usually use cognito as an user directory to generate unique user ids and integrate with other aws services.
like DynamoDB with item-level control based on the Cognito User Id, which is handy:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_items.html
https://aws.amazon.com/blogs/mobile/building-fine-grained-authorization-using-amazon-cognito-user-pools-groups/
making it easy to create and manage user devices token etc
but maybe there’s better ways.
hope never dies 😆
We are currently developing a cloud solution that would require 2000+ clients to publish events (1-2 per second) into an Event Hub. We built a prototype that gives each client a Shared access policy (Authorization Rule), and creates a SAS token with a publisher policy as defined here
We thus are able to identify the publisher of each event by inspecting the x-opt-publisher system property, and to revoke access to the Event Hub for each client at any time, without having to resort to token expiry and renewal.
However, we recently learned that the maximum amount of SAPs / Authorization rules is 12, so this solution ultimately will not work.
Is there another solution to this problem? Our goals are:
Avoid having to use token refresh, as this would require adding code to all clients.
Being able to revoke access to the Event Hub instantly in case a client either gets compromised, misbehaves, malfunctions due to a bug, or the associated customer's contract is terminated
Avoid having to use a frontend service authenticating the clients, as we are talking about a substantial additional system load (5000 requests per second)
Avoid having to use IoT hub, as the costs are far higher than with our solution, and we do not need all that functionality
Thanks in advance
You don't need to create a dedicated SAS policy for each device or publisher. Please note that a publisher should only own a token signed for itself and should not be able to access the SAS policy key.
Feel free to check the publisher policy document here for more details.
I am using Amazon SNS in order to send push notifications to my React Native mobile app. There is a requirement to cleanup the Topics/Subscriptions in SNS when a given user uninstalls the mobile application or leaves the company (the app will be remotely wiped once the user leaves the department/company).
I've done some research in SNS documentation and found out that it is up to APNS and FCM to notify SNS that a given device token associated to a particular installation of the app on that device is invalid. I do see disabled Endpoints in SNS (meaning that at some point APNS/FCM did provide feedback to SNS about invalid token), however, I need to know how long does it take for this feedback to get delivered to SNS. I tired to uninstall the application from our test iOS device and send a notification through SNS console to the device and the console returned a successful delivery message:
Message published to endpoint
arn:aws:sns:us-east-1:ACCOUNT_ID:endpoint/APNS/APP_ID/ENDPOINT_ID
successfully.
I need to know the time it takes for APNS/FCM to provide the feedback in order to implement a scheduled cleanup process involving deletion of disabled endpoints in SNS.
This is my first question on StackOverflow, I am glad I joined this community!
Thank you for your feedback.
I'm trying to wrap my head around how AWS Mobile Push Notification works. Specifically I'm building out a web service that will be capable of sending notifications to my mobile app running on my users' devices. After reading all of their docs, it sounds like the high level flow is:
Configuration
I need to go into my respective Push Notification Services (GCM for Android and APNS for iOS) and configure them to get credentials that I configure my backend service to use for connecting to them at runtime
I need to log in to the AWS SNS console and generated a platform application ARN (PlatformApplicationARN) that I also configure my backend to use
Code Flow (Runtime)
When a new user signs up for the first time, or anytime an existing user signs in on a new device, I have the app send my service their device info. One critical piece of this device info is their device token (also referred to as a "registration ID" in the AWS docs). This token is generated by their OS and uniquely identifies their device within their respective Push Notification Services (again either GCM or APNS for me)
When my service receives this new device info, I save it, and I also use the device token to hit the AWS SNS API (along with my configured PlatformApplicationARN) to generate a unique EndpointARN for that particular device
Now, whenever my backend decides it needs to send a notification to that user, I can look up all the devices associated with that user (that I previously stored in my DB), and fetch each device's EndpointARN. Then its just a matter of hitting the AWS SNS API to send my notification message to that EndpointARN, and it sounds like AWS SNS will take care of everything else (and delivering the actual message to the device)
So before I go any further, I'm just looking for someone to help sanity check my understanding and provide any course correction if I've misunderstood anything or am missing any important pieces of the config/flow! Assuming I'm more or less on track...
I'm still not seeing how SNS will be able to connect to GCM and APNS once I send a notification message to an EndpointARN. Do they maintain their own integration/connection with these services? Or do I somehow inject my own GCM/APNS credentials into the AWS SNS API call somehow?
Also, I know push notifications can be fairly configurable, allowing you to do things like:
Determine what sound the device should play when it receives a notification
Determine what color LED to blink on/off when it receives a notification (on my Android phone, different apps cause green, blue even purple LEDs to blink!)
Determine whether the notification is received by the Android/iOS OS itself (in which case if I come back to my phone after being away from it for a few minutes, I can press any button and see a high-level listed summary of any new notifications I've received); or whether the notification is purely an "in-app" notification in which case I'll only see that I received it if I actually open up my app.
I'm wondering where all this configuration takes place? Any ideas?
I can confirm that the high level flow is:
Log into AWS SNS and create 2 different Platform Applications, 1 for Android (FCM -- Firebase Cloud Messaging) and the other for iOS (APNS -- Apple Push Notification Services)
For each Platform Application you'll get a PlatformApplicationArn and you will be asked for credentials so that SNS can connect to your respective FCM/APNS accounts
For FCM you will just need your Server API Key (this can be obtained from Firebase Cloud Manager)
For APNS you will need to go through a really labor-intensive process of creating certificates through the Key Chain Access tool on your Mac, this was not fun...
Add these 2 PlaformApplicationArns to your code's config
When a user registers a new device with your app, they will send you a device token (provisioned by FCM or APNS) that uniquely identifies them to FCM/APNS
Take this device token, combined with your PlatformApplicationArn for FCM or APNS and use the AWS SNS SDK to create an EndpointArn for the device. Store this EndpointArn however you like.
Now you can use the AWS SNS SDK to push messages to your EndpointArn (specific device) anytime you want to.
Our apps are being developed for both Android and iOS. We are using AWS SNS Mobile Push to push messages to both GCM and APNS. The back end is PHP and so it uses the AWS PHP SDK.
Until now, our system has been saving 1 Endpoint ARN per user. We then broadcast a Mobile Push message directly to this Endpoint ARN.
The question:
It would be strange if a user were logged into our app on multiple devices and did not receive push notifications on all of them. So - we're going to have to change something.
How, in AWS Mobile Push, is the concept of 'one user, multiple devices (and potentially multiple platforms) handled?
Does our system have to maintain a one-to-many association of user-to-EndpointARNs (i.e. start saving multiple EndpointARNs per user so that we may push messages to all of them sequentially)?
Or should I be looking into the 'Topics' concept that Mobile Push provides (I'm confused here - do some people use one topic per user, and then push messages to the topic itself?)..
Lastly - I guess as a bonus question - is it normal for people using the PHP AWS SDK to include both APNS and GCM attributes in the Message payload array? We haven't been keeping track of 'which type of device each user uses'. We've just been saving an Endpoint ARN per user. And I guess the thought was to just cover all our platform bases (APNS, APNS_SANDBOX, GCM) when we're pushing a message to an endpoint.
I've been doing a lot of searching on the 'one user with multiple devices' topic re: Mobile Push with AWS SNS, and really the results have been quite unhelpful.
Help please :(
Thanks!
Once you send SNS Push message , you will get success or failure reason.
Could you please check your logs and share to identify exact issue.
Cloudwatch :
SNS publishes Cloudwatch metrics for number of messages published, number of successful notifications, number of failed notifications and size of data published. Metrics are available on per application basis. You can access Cloudwatch metrics via AWS Management Console or CloudWatch APIs.
Direct addressing:
Direct addressing allows you to deliver notifications directly to a single endpoint, rather than sending identical messages to all subscribers of a topic. This is useful if you want to deliver precisely targeted messages to each recipient. When you register device tokens with SNS, SNS creates an endpoint that corresponds to the token. You can publish to the token endpoint just as you would publish to a topic. You can direct publish either the text of your notification, or a platform-specific payload that takes advantage of platform-specific features such as updating the badge count of your app. Direct addressing is currently only available for push notifications endpoints.
Official documentation, "When a topic is created, Amazon SNS will assign a unique ARN (Amazon Resource Name) to the topic.
https://aws.amazon.com/sns/faqs/
I have a solution for this issue as you already know ARN is associated with single device token so you must be manage it own your own to send push to same user with multiple device.
My approach is to create 2 table in mysql or whatever database you are using
1. For APNS or, APNS_SANDBOX having details like user_id(local), device token, endpoint ARN, status etc (EG : sns_apns)
2. Same for GCM or BAIDU you have to create a table having user details with endpoint ARN(EG : sns_gcm)
Now every time when you send push to a particular user just write a code something like this
Switch($platform) {
case 'APNS':
case 'APNS_SANDBOX':
Select all users from sns_apns by login id.
Create a message and send it to all users having same user id
case 'GCM':
Select all users from sns_gcm by login id.
Create a message and send it to all users having same user id
}
I haven't tried this but to solve your problem I would keep a map of the user's cognito userID and corresponding endpoint ARN for each major app defining transaction done by the user. If the endpoint already exist then no need to save it. But if for this userID another endpoint ARN is notice then save, update, add or associate this new endpointARN with userID in DynamoDB as a #Document attribute. Then at anytime just broadcast to all endpointARN associated to the userID in DynamoDB.
The mysampleapp mobile hub example codes are useful for quick manipulation. For android:
Get the endpointARN in app like this:
PushManager pushManager;
String userDeviceEndPoint;
pushManager = AWSMobileClient.defaultMobileClient().getPushManager();
userDeviceEndPoint = pushManager.getEndpointArn();
You can update DynamoDB using the update save behaviour to ignore if an already existing endpoint is noticed for the user:
DynamoDBMapper mapper = new DynamoDBMapper(ddbClient, new DynamoDBMapperConfig(DynamoDBMapperConfig.SaveBehavior.UPDATE_SKIP_NULL_ATTRIBUTES));
Not sure how to do this in PHP though. Hope this idea helps.