I currently have a table in a mysql database with all the apn tokens of the users of my iOS app.
Every 24 hours my server runs a script that sends a notification to each user in the table.
I am sure some users are no longer active/have deleted the app and I was wondering if there is a way to identify them/remove them from this table?
The notification involves making a call to a weather api service (which is not free) so I am trying to avoid making unnecessary calls!
The Apple doc says if you get a
400
http code with
BadDeviceToken
as reason then
The specified device token is invalid. Verify that the request
contains a valid token and that the token matches the environment.
I check every response from the APN and invalidate/delete bad tokens from my database.
But you still need to do your weather request one more time for each device until its deleted from your DB.
You could send a silent notification before your request to check if the device token is valid, but that would be two notifications for one.
Related
I have an app that uses the Twitter API where users can authenticate via twitter and retweet/like/follow through my app. Randomly this week the logs are showing "code: 89 Invalid or expired token".
Naturally, I go login to twitter to see the status of my app, and nothing seems out of the ordinary. I saw others with this issue had success regenerating their keys and replacing them in their application.
This didn't help.
One important thing to note is nothing has changed in the code of my application for the last 3-4 months, so I doubt it's anything in there. It's been working for over two years without any issue.
The thing I suspect the most is perhaps Twitter decided to suspend my app; Although, I don't see anywhere that is the case, and I thought I'd receive an email from them about it if it were.
I'm at a loss and would appreciate some possible solutions or alternative avenues I can pursue to find the culprit.
The keys associated with your app are the API Key (Consumer Token) and API secret key (Consumer Secret). The error you're getting is for the Access token, which belongs to the user. It sounds like the user associated with that request needs to authorize your app again before it can operate again with their access key. This can happen if the user removes authorization for your app by visiting their Settings/Privacy and safety/Apps and sessions.
If you were using your own access token in a scenario like single-user authorization, then regenerating the key might work, but in this case, the only way to get new keys for that user is for them to go through the sign-in process to authorize your app again. e.g. you could log who the user was that the error occurred on and send them a notification to re-authorize.
I've successfully setup my hub to use an SSL certificate per app, but I'd really like to move to the token-based APNs Auth Key approach. I configured my hub with I believe all the right information from the p8 file. For Key ID, I put in the 10-character value from when key was generated. For App ID, I put in my Team ID. For Token, I put in the private key value from the p8 file.
Has anyone had any success with this? Here's what happens when I attempt to send a test message:
When set to sandbox and I do a test send to my device, I get a failed outcome of "The Push Notification System rejected the request because of an invalid credential".
When set to production and I do a test send to my device, I get a failed outcome of "The Token obtained from the Token Provider is invalid"
For production, I think that is because I'm sending to a local app build outside of TestFlight/app store, so it is expecting the "development" or sandbox aps-environment.
Not sure what other troubleshooting I can do.
TIA,
I figured out what was happening for me.
The App Name field in the Azure Portal is critical to how the message gets delivered. Even though an APNs Auth Key can be used across multiple apps, the notification still must set the topic to be for that particular app. It seems like Azure Notification Hubs take the App Name field and put it into the apns-topic. Once I had that set to my app identifier, it worked as expected.
Also as an FYI, here is the link to the official documentation
https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-http2-token-authentification
I use GCM in my Swift app and would like to ask GCM a new registration token.
I know that it's done automatically by GCM and I handle it in onTokenRefresh, but I want to know if it's possible to request GCM to refresh the token manually (to have a different one).
I tried to unregister for remote notification and register back to run the process (tokenWithAuthorizedEntity etc ...) but the registration token sent is the same.
any solution to do this ?
Use the deleteTokenWithAuthorizedEntity: method before asking for a new token as derived in the official docs. Also, if that fails, delete the Instance ID itself, which will delete all tokens associated with that Instance ID, in which case make sure to also call getIDWithHandler: before asking for a new token.
Anyway, why do you need to refresh this token? Although you can delete them, this is not their intended use. If you're just looking to ID a particular device uniquely, use the Instance ID itself OR use alternate methods of generating random strings (and then re checking if this random string has actually never been generated and used before).
I am very confused by the BC documentation on their API, because they let you create "Draft Apps" (private apps) and now I see that in their documentation they say "We do not currently provide a means of keeping OAuth apps private.".
My concern here is that they made some changes recently that might have affected a few of my Private Apps that I had running just fine a month ago. If anyone can provide some insight, I would appreciate it greatly!
https://developer.bigcommerce.com/api/guides/oauth-transition
There is nothing wrong with creating oAuth credentials with a "Draft App" for the sole purpose of accessing the API of your store. You do not ever have to publish your app and your app will never be made "public" in that case. You also don't have to bother with the 'Load Callback URL' and filling out the details on your draft app, unless you want to provide yourself an interface in the store.
The "Draft App" function was specifically meant to allow Developers building apps for the BC App Marketplace to test their apps in a store before submission. However, you can use it to make a private application that is only intended for your store - I'm including the process here for others!
Making a Private App with oAuth (or How to Generate oAuth Credentials for a Store)
What you will need
Access to the account listed as the "store owner" of the store where you want to install your app or the ability to get a person with access to complete a couple steps
Ability to setup a local or public URL to receive the 'Auth Callback Request'
Getting started
The first thing you should do is sort out making available a local or public URL that can receive an "Auth Callback" request. This resource must be able to work over an HTTPS connection but the SSL can be self-signed. The 'Auth Callback' request from Bigcommerce is a GET request that will have 3 query parameters on the URL: code, scope, and context.
It is described in greater detail here:
https://developer.bigcommerce.com/api/callback#get-req
Additional info
When building a public app it is important that the service receiving the Auth Callback request be configured to catch the 3 query values and combine them with information you already have. You would then send all of this information in a POST to the BC oAuth Token service to generate your API token for the store. In addition to that you would want to respond to the Auth Callback request with a 200 status and an interface, or instructions, for the user.
In the context of building a private application you don't need to worry about any of that. All you need to do is capture the query values. If you have this already then go ahead and jump down to the section on generating an API token below.
Before Moving On
You should have a URL path that can receive a GET request and captures query parameters. Test it out and make sure it works. Here are a couple example URLs:
https://example.com/auth-callback
https://localhost:8000/auth-service
Registering an App
The key point here is that the registration of the app must be completed by the store owner account of the store where you want to install the app. If you have access to the store owner account credentials then follow the steps at the bottom of this page:
https://developer.bigcommerce.com/api/registration
If you are working with the store owner then you can direct them to complete the steps above. You will need to provide them the Auth Callback URL you created for completing Step 9. The Load Callback URL does have to be filled in but the default example provided can be left in place.
SCOPES
When registering an app you are able to choose the scopes for the app. It is simple to just leave them all open but it is best practice to only enable the scopes you need. Here is a list of the scopes:
https://developer.bigcommerce.com/api/scopes
If you are not sure whether or not you will need a certain scope then leave it enabled because you will have to re-generate your API Token (perform a re-install of the app) if you have to change the scopes on your app.
Before Moving On
You need to have the client_id and client_secret. If someone else registered the app then you will need to ask them for this. There is a View Client ID button that will provide it after registering an app.
Generate the Auth Callback Request
You will need the person with store owner access again for this step. They will need to login to their store and go to the Apps section on the left side column. After that click on Marketplace -> then My Apps (in the top-right) -> then My Draft Apps
You should now see a list containing any "apps" that the store owner has registered. Choose the one relating to the client_id you plan to use. Click to install the app.
The Auth Callback request has now been sent and you are done here. You should expect to see just a blank or grey page as a result unless you are responding to the Auth Callback request with content. Your app is now awaiting authentication.
If using a self-signed certificate
When your Auth Callback URL has a self-signed certificate then you will see a "untrusted cert" error in your browser when you attempt installation of the app. You should choose to trust the certificate and continue.
Before Moving On
You should now have received the code, scope, and context at your Auth Callback URL. If you did not it was likely due to not having SSL/TLS at your server. You can replay the Auth Callback request as many times as needed by Cancelling Installation of the app in the same place where you started it. You can even open up a Dev tool and watch the request happen to see what errors show up in the console. If this is continuing to fail then you should reach out to Bigcommerce support or ask a new question on here!
Generating an API Token to Complete Installation
Follow the steps here:
https://developer.bigcommerce.com/api/callback#post-req
You should have all of the details needed to send a POST request to the BC Auth Token Service at https://login.bigcommerce.com/oauth2/token
Make sure to URL encode your content and you should be good! Here is a site that can URL encode and decode for you: http://meyerweb.com/eric/tools/dencoder/
Just be careful of it encoding & and = signs when those are actually being used as separators between fields or between field/value (respectively).
Before Moving On
You should have received a successful response from the Auth service which will include your API Token. Once you have this you are all set to access the API of the store. You no longer need to have your Auth Callback URL up and available and can take that down.
Also take note of the context to use to create your API path.
Accessing the API
Now that you have your API Token and context you are all set to access the API of a store. Start off with a simple request to the /time endpoint.
Make a GET request and include the following headers (minus the curly braces):
X-Auth-Client: {CLIENT_ID}
X-Auth-Token: {API_TOKEN}
Accept: application/json
Content-Type: application/json
Send your request to a URL path of (minus curly braces):
https://api.bigcommerce.com/{context}/v2/time
If you get back a 200 response then you are all set!
Additional Notes - Ways to Break Credentials
Once you have successfully generated an API Token for a certain app, that app will display in the Control Panel as an icon in the Apps section. The fact the app is there shows it is installed and allowing access. If you uninstall that app then the previously generated API token will stop working.
Changing the scopes on an already installed app will require it to be re-installed to correct the token.
Changing the store owner email on the store will cause the token to stop working. The API Token is specifically tied to the store owner that registered the app.
if you have apps in "My draft apps" and you used basic oauth, you will have to change to Oauth Authentication, but if only have private apps using "legacy api account", you will not need to change.
We have a server to send notifications to our users on iOS and Android. Android works fine.
The problem is, when an user uninstalls and reinstalls our app. The app then requests a new push ID from GCM with its APNS ID(which is still the same) and sends us the new ID. Now we have 2 records to send notifications to. It looks like GCM just maps its generated ID to APNS ID in a simple N:1 relation.
If we had the same situation in Android and we now send our notifications to GCM, it would send the canonical ID in the first response, so we can react to that to not send a second notification. But with iOS it does not. The response looks like a normal, complete, successful request.
Did we miss something or didn't GCM implement canonical ids for iOS? I couldn't find any information regarding this problem.
A registration token is per device per installation.
Every time you uninstall and reinstall your app (either iOS or android), GCM will give you a new registration token.
It is a similar concept to Canonical IDs. If you get a Canonical ID, then you need to replace your old registration token in your server with the newly returned Canonical ID, as eventually the old registration token will stop working.
So, if you get a new registration token back when you uninstall and reinstall your iOS app (or Android app), you can simply compare the newly returned token with the old one. If the new token is different from the old token, then you can just replace the old one with the new one in your server so that you dont need to maintain 2 tokens in your server.