I am a little confused about this migration path, as described in a recent aws blog post, and its aftermath:
It seems like quite a bit of trouble to have to rely on all my users to update in a timely fashion so that GCMSenderIDs can be attached to my existing parse data along with modified/valid device tokens.
Also, what happens to new installations after the migration is complete? In the guide it says no changes need to be made to client side code, but doesn't this require that the SNS sdk is installed so that new installations can be added to the client list?
Considering all this, wouldn't it make a lot more sense to simply forget about the old parse data and just push a client/app update that works solely with SNS and reregister all the devices that way? Why go through all the trouble to integrate with Parse when we are getting rid of it anyways?
AllTheTime,
Your existing Android user push tokens on Parse.com will no longer be valid after January 28, 2017 as Parse owns the API Server Key associated with the Sender ID that was granted the token. If you wish to reach those existing users via Push Notifications after January, you must update the existing Parse.com client app with your own Sender ID and have the app generate a new registration Id (token) associated with your Sender ID. There is no other way for you to convert the existing tokens over to SNS or any another 3rd party.
The SNS SDK is not required for the migration but it would make sense to integrate the SNS SDK when you update the app to retrieve new tokens using your Sender ID. At the time of token registration, the app can update the Parse.com database with the newly issued token AND also create a new Platform Endpoint with SNS.
As for post Parse Push migration and handling the new app installations, my suggestion is to build an after-save “webhook” on the _Installation class on Parse.com. The “webhook” would trigger any http endpoint when a row is created or updated in the _Installation class. The hook could trigger an API Gateway http endpoint that takes the newly generated or updated token and creates a new SNS platform endpoint. At this point, if you haven’t fully migrated from Parse.com, you can either publish to those tokens via Parse.com or SNS. By the time Jan 28, 2017 rolls around, nearly all your existing users would have launched the updated app and generated a new token or they no longer use your app.
Starting over with just SNS is another option but if you need to reach any of the users who have not updated the app then you would need to continue sending push notifications through Parse.com for those legacy users who have not updated the app AND you would then continue to send push notifications via SNS to those new app installs.
I hope this clarifies the migration for you.
Check out my other SO post regarding the Parse.com GCM Sender ID:
How to migrate off Parse to different SENDER_ID
-Dennis
Related
I am a bit confused on how does Authorize.net work and how to integrate it, in my project I am using Angular as frontend and node.js as backend and I have installed Authorize.net via npm install authorizenet also cloned the Node.js sample code and I would like to set Authorize.net like so.
Let's say I have a form on my website where the customer needs to enter their details including the credit card details, my question is when submitting (using HTTP Request Method: POST) does my website need to redirect to Authorize or is there a widget that Authorize uses that I can implement in my website or are the details send directly to Authorize and handled there.
On submitting the details from the website do I simply call let's say the function from the sample codes (modified for my site) charge-credit-card.js ?
After that where do I receive the response, do I need to somehow capture it ?
Do I simply use the Production API Endpoint: https://api.authorize.net/xml/v1/request.apiand use my Api login and transaction key to use Authorize, at least that's the way in the documentation from my understanding - After building the XML object for an API request, submit it to the Authorize.net payment gateway as a standard HTTPS POST to an Authorize.net API endpoint. The exact process for doing this will depend upon the development language that you use.
Thank you in advance.
Your server will never know the customer's credit card details.
when user first time registers in your site then you will create one customer for authorize.net using this code and you will save the customer id returned to your db for future reference.
To Update customer's credit card details:
create one API controller from your node server which will return authenticating token from authorize.net to your frontend. Get token code
Your front end will make call to above created controller's API and get the authorize.net token.
Now, your front end will use this token to get the update details form from authorize.
Then you will use authorize webhook facility to know if user has updated theit payment details or not.
Webhooks to be tracked:
net.authorize.customer.paymentProfile.updated
net.authorize.customer.paymentProfile.created
On receiving below notifications, your node server will perform the whatever task required.
Refer this doc for more details.
I have integrated aws amplify into and android app by following https://docs.amplify.aws/lib/q/platform/android in my mac book pro.
Now I check-out the same project into another machine mac mini. and trying to run.
I am getting this error, not sure how to fix it.
AmplifyException {message=Failure performing sync query to AppSync: [GraphQLResponse.Error{message='You are not authorized to make this call.'
tried, amplify pull, amplify configure, amplify init. but none are able to resolve this issue.
thanks in advance
Initially, you will see your graphql in Network tab failed because of Authorization.
"My case is App Sync API key is expried. – Freddie Jun 26"
This is the answer, go to Appsync / Settings / API keys.
You will see the "red" key. That means it has expired.
You just need to create a new key. Then replace this new key for appsync api inside your aws-exports.js under name aws_appsync_apiKey
If you have resolved this, I'll just leave it here so someone else can see it.
Ah! Great news, you can simply edit the date (no need to make a new one).
It's just that the default is one week.
Go to your ordinary, full, normal AWS console. GO to "aws appsync".
Then ..
If your token expired (here I'm talking about a token that was living its max 365 days and has expired) and you by any chance are publishing your application to AWS using amplify, you will need to add new token to application (simply changing it in awsexports would not be enough). To do it you must:
Find the file amplify/backend/<your_app_name>/parameters.json and there add two lines (this might be just CreateAPIKey but I've tested just one method found in this github issue and it worked).
"APIKeyExpirationEpoch": -1,
"CreateAPIKey": -1
Run amplify push. This should delete the old token. But you will be better off checking it yourself in Appsync/settings/api keys. If you have no tokens there, then you are good to go.
Go back to parameters.json file and remove our parameters (APIKeyExpirationEpoch and CreateAPIKey).
Run amplify update api. Choose your api (mine was Graphql). Choose update auth settings. Choose your default authorization method (mine Api key). Enter description for your api key and add the ttl for your api key (default is 7 so I suggest changing this one). Don't configure additional auth types.
You should get success message at the end. Now do amplify push. After a while the command should return success message and you are good to go. To double check you can verify token in your appsync. There should be one token only. Alson you can check the api calls for x-api-key value in header which should hold your new token.
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.
I am new on Amazon SNS.
I have apps that are using APNS and GCM through Amazon SNS.
So every time a user installs my app, I would register them into GCM or APNS.
I wanted to know when app my app has been uninstalled so that I can remove them in my database and they won't be sent a push notification.
I read somewhere about Apple Feedback Services and GCM returning NOTREGISTERED, but explanations are very unclear to me like where can I get these services and responses?
Any help is greatly appreciated!
Thanks.
Based from this blog, In order to push mobile notifications to an app using SNS, that app’s token needs to be first registered with SNS using the CreatePlatformEndpoint API method.
The best practice presented below creates a working, current, enabled endpoint in a wide variety of starting conditions. This approach works whether this is a first time the app is being registered or not, whether or not the PlatformEndpoint for this app already exists, and whether or not the endpoint is enabled or disabled, or has the correct token, and so on. The approach is also idempotent. It is safe to run it multiple times in a row and it will not create duplicate PlatformEndpoints or alter an existing PlatformEndpoint if it is already up to date and enabled.
retrieve the latest token from the mobile OS
if (endpoint arn not stored)
# first time registration
call CreatePlatformEndpoint
store returned endpoint arn
endif
call GetEndpointAttributes on the endpoint arn
if (getting attributes encountered NotFound exception)
#endpoint was deleted
call CreatePlatformEndpoint
store returned endpoint arn
else
if (token in endpoint does not match latest) or
(GetEndpointAttributes shows endpoint as disabled)
call SetEndpointAttributes to set the
latest token and enable the endpoint
endif
endif
We have been using Amazon SNS to send Android push notifications since April this year.
Pushes have sent with no problem, however there has never been any record of calls to the Cloud Messaging API in the Cloud Console (seems odd?).
Today I created a new API key for the Static Map service (unrelated) and renamed our Cloud Messaging API key (only the name, the key is the same). From this point no pushes have been sent, and trying to create a new platform application (or update the existing one) in AWS results in:
Invalid parameter: Attributes Reason: Platform credentials are invalid (Service: AmazonSNS; Status Code: 400; Error Code: InvalidParameter; Request ID:)
I have also tried manually making calls to the https://gcm-http.googleapis.com/gcm/send endpoint using the key which results in Unauthorized (401).
Interestingly, I can make calls to the above endpoint using the key I created today, however they fail on MismatchSenderId.
I can't see a lot of the previous options that the Cloud Console had (server / browser keys, etc) within the API Manager?
For those who are facing this in 2017, here goes a tip:
1 - Go to your firebase console (https://console.firebase.google.com/) click on your project (which you want to use for push notifications)
2 - Click on the "three dots" on the right side of your project name and click on "Settings"
3 - Click on "CLOUD MESSAGING" on the header tabs
4 - Copy the "Server Key" (this one is bigger than your API key)
5 - Paste on the "API Key" input of the AWS Form for "Create platform application"
PS: Note that this is valid only for GCM Push Notifications.
API Key management for GCM has been moved to Firebase Console.
You can create a new Firebase Project (or import an existing cloud project) and you should obtain a new Server Key for Cloud Messaging.
see the updated documentation:
https://developers.google.com/cloud-messaging/android/client#create-an-api-project
and the stack overflow question: Where can I find the API KEY for Firebase Cloud Messaging?
if you still have problems please contact:
https://firebase.google.com/support/contact/troubleshooting
I have been getting the same error when creating Amazon SNS platform application:
Invalid parameter: Attributes Reason: Platform credentials are invalid (Service: AmazonSNS; Status Code: 400; Error Code: InvalidParameter; Request ID:)
After reaching out to the Firebase support as suggested by Diego, this is the response I got from Google:
Hope you're doing well and thanks for reaching out to us.
I'm not really familiar with Amazon SNS and looks like their integration is still with GCM, not FCM. If your app implementation is still GCM, then you need to migrate with FCM in order to use the server key in the console. See the instructions here.
Also, Firebase has upgraded the server keys to a new version. We'd recommend to use the server key instead of the legacy server key.
I hope this helps. Let me know if you have any other concerns. Thank you.
This indicates that we'll have to change our app code. We were able to make this work for another app in out organization by creating a new firebase project and using the Legacy server key with Amazon SNS.
At some point we'll definitely upgrade to using FCM but at the moment we have a tight deadline.
Update:
So finally what worked for us is using the 'Server Key' under Project Settings --> Cloud Messaging . The app still uses the GCM implementation. Amazon SNS is happy with this key and generated a GCM platform push application. The pushes work !
Still confused about why the 'Legacy Server Key' does not work for one app but is ok for the other. But I am not digging into it any further.
For those starting a new project and wondering why it is still invalid, make sure the application Key restriction is set to Android apps. In my case, it was at only set to None and when I switched to Android apps, it worked after 5 to 10min after updating it. You'll need to add your package name and SHA-1 certificate fingerprint.