I'm developing an iOS Project using a Braintree Payment roll for transaction processing. I'm using the API at SCViewController.m line 86 from the Braintree iOS Library and that code was working perfectly.
I created a new Braintree Sandbox accout and put its encryption key into our project, but now I get this error:
Problem acquiring reference to the public key, OSStatus == 0
What do I need to do to make the new encryption key work in my project?
The SampleProject is creating a VTClient object here. When that object is created, you pass in your Braintree client-side encryption key and your merchant ID.
That error is happening because you're passing in an incorrect Braintree client-side encryption key. Please make sure that you're using the correct sandbox client-side encryption key and sandbox merchant ID, which can be found logging in to the sandbox Braintree site.
Also, keep in mind that there are different client-side encryption keys and merchant IDs for sandbox vs production environments. When you create the VTClient, you can specify which environment you're working in - and ensure that you're passing in the appropriate credentials for that environment.
Braintree dev here - as a result of some recent internal upgrades, a small number of CSE keys in our sandbox were generated incorrectly. From your error message, it looks like you may have been bit by this issue.
We've regenerated keys for the affected users. If you go back to the Sandbox and copy your new CSE key, it should now work. If it doesn't, please reach out to our support (support#braintreepayments.com) directly and we'll be in touch.
Thanks,
-SP
Related
I have an app that uses stripe payments and I am trying to allow users' cards to be charged. I have successfully changed the pk_test to pk_live but I am having issues changing sk_test to sk_live. I had paid someone to install stripe for me, and the only reference I can see to sk is inside of node.js as
const stripe = require('stripe')(functionConfig().stripesecretkeys.key);
This leads me to believe that the individual used terminal to reference the sk_test. My question is, how can I change this to be live instead of test.
I see this on firebase Doc,
firebase functions:config:set stripe.secret=<YOUR STRIPE LIVE SECRET KEY>
EDIT:
I have managed to add the secret key in through terminal, but when I create a new customer they are still being created under test mode on stripe? am I missing something?
I am trying to hook a Xamarin project up to Google Play Services but keep receiving a SIGN_IN_REQUIRED error when calling Connect. I have read a few posts online but cannot determine what actually causes this error message.
I have setup the a game project and also setup an API with oAuth credentials. I have made sure that the same SHA key is being used in the API credentials and in the application while debugging but I am still not making any progress.
I am currently presuming that this is not a coding problem but rather something to do with the setup of the API services etc but have ran out of things to try at this point.
Firstly, to make sure your network connection is normal, you can run this demo in your network environment.developer.xamarin.com/samples/monodroid/google-services/… Donnot forget to change to clientID in string.xaml.Then , open the firebase console, find this app check the clientID if it is same with your code, and check the SHA-1 hash of your signing certificate.
I am reading the documentation for both push using TLS certificates and push using authentication tokens
But besides explaining how to configure each, the articles don't really explain the differences or pros/cons of both approaches. Can somebody explain them to me?
Token-based authentication is newer and essentially simplifies APNS authentication.
It is based on a public and private key pair that you can generate on your Apple developer account.
Here are the main reasons why it is simpler:
The same key can be used for development and production apps whereas
different certificates are needed when using certificate-based
authentication.
The same key is used for all your apps referenced in your Apple
developer account. Certificate-based authentication needs one
certificate per app.
The key does not expire. Certificates do expire and need to be renewed every year or so.
A good source of intel is the 2016 WWDC video regarding APNS:
https://developer.apple.com/videos/play/wwdc2016/724/
For 2020, you can only realistically use the "token" method. The older approach is legacy and they will probably axe it.
Your private key will look like this
let keystring = `-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49Aas8d76as8das687asd687asd68as8brwUIWA46qcXis
zCu6dbd4s8d7b5s86gf98ugtr28re7089a7d6tbvpiiui524kyfpq9861eFJP7we
eE7rX4182609457ohgyj3lhgp98wfb698bfg69287f2k4htgwpo876grwo7XDklz
9fdg689d
-----END PRIVATE KEY-----`
your key id will look like this
let keyId = "CTU7XXBPRH"
and your Apple team id is your usual Apple team id, which looks like "YWD3UUTEWD".
Nowadays - thank goodness - it is relatively easy to get the private key and key id from inside your company's account on the Apple developer website.
If you want to test sending a push on an ordinary Node server on AWS, I strongly recommend this outstanding new npm, APNS2 https://www.npmjs.com/package/apns2
let bn = new BasicNotification(deviceToken, 'Hello')
It's about that easy to send pushes.
Tips:
Don't forget the damned "development/sandbox" pushes only work ON AN IPHONE TETHERED TO YOUR MAC/XCODE!
development/sandbox pushes - only for an iPhone tethered to your Mac with a build running from Xcode
production pushes - they do work completely fine with TestFlight builds.
Additionally: don't forget that the so-called development/sandbox pushes are often flakey. Often, they don't arrive for hours, they don't arrive at all, they simply don't work in many regions.
Don't forget that it is TOTALLY OK to use the "production" ones, simply, with a TestFlight app.
So
Make a build
Push it to your TestFlight account. Wait a few minutes as usual until the build comes through,
Install it from TestFlight to your phone
You will now get all the pushes - instantly!
Whereas if you
Make a build
Just build/run to your tethered iPhone
You do NOT get any pushes.
It's true that you can get the so-called "development" pushes, but they are often very flakey.
(To be clear, when using APNS2, if you do want to try "development" pushes, to order "development" pushes, simply use the extra line of code explained at the bottom here https://www.npmjs.com/package/apns2 )
In 2021, Apple's Setting Up a Remote Notification Server state
Both techniques have advantages and disadvantages, so decide which technique is best for your company.
Both Fattie and Ika have said that TLS/ Certificate based authentication is inferior. The Project UI in Firebase also uses language which doesn't explain much IMHO:
Configuration with auth keys is recommended as they are the more current method for sending notifications to iOS
Benefits of Certificate Authentication
Limited access certificates. Each certificate is tied to one application in your developer account and environment (development/ production). This avoids putting all your eggs in one basket, if your token auth key is compromised, a threat actor can push notifications to all your applications.
Simpler Provider application logic. The provider (service which interacts with APNs) (either your own server or a service you use) can just use the TLS certificate, and authenticate, without needing to create JWTs, add headers to the request or find the correct App ID to use.
Benefits of Token Authentication
Simpler setup process: because you only have to download a .p12 and use it your application. Go into developer.apple.com, create a Push Notification Key. However, your application has to renew these tokens every hour. Creating a .p12 for TLS authentication is a little bit more involved.
Does not expire, so you can set it and forget it. Whereas TLS certificates expire in 1 year by default.
The question boils down to security vs. convenience.
Convenience (use token auth): It's convenient to create a key and forget (token auth), and you might use Firebase (or another service) to actually renew the tokens every hour, so you don't have much work to do.
Security (use TLS auth): Do you really want to share the same key between all your applications? What if you want to limit the scope of a Push Notification Service Provider (e.g. Firebase, Ably, Pusher), but don't trust giving them access to all your applications. In reality, you might just have 1 application, so it does not matter.
Does this kind of even security matter, or is it just more convenient to use Token Auth? I would say in most cases, go with Token auth.
I'm trying to integrate the Google Data API into my application. I'm using the ObjC wrapper available here:
http://code.google.com/p/gdata-objectivec-client
but I have got some issues with the authentication. Basically I'm following the steps as described here:
http://code.google.com/p/gtm-oauth2/wiki/Introduction#Signing_In_to_Google_Services
I have created a project on the API Console and added two client IDs for installed applications: one is of the "Other" platform, the other is "iOS" with the bundle ID appropriately set (though I left the appstore id 0 for the moment). Now comes the interesting part.
Both the YouTubeSample app bundled with the above wrapper library AND my iOS app work perfectly with the client ID belonging to the "Other" platform, and both of them return a 400 invalid_client error when I switch the ID for the iOS one. I have doublechecked the client IDs and secrets, all are correct. The iOS app has of course been given the correct bundle ID.
So, am I missing something trivial here?
Is there a reason that you need to use the iOS-type id/secret pair instead of the other-type pair? Perhaps I'm missing something, but the linked documentation states to not use an iOS type client id:
In the console, create a project, then click "API Access" in the left column. Create a new Client ID for an Installed Application (not a web application) type other (not iOS). This will provide Client ID and Secret strings to be used with the controller.
The controller likely doesn't identify itself as an iOS application when sending the requests, which Google probably checks when it receives an iOS id/secret pair.
I want to sign a BlackBerry application with the 3 CSI files I have. When I install new keys, I give the associated user id and password, but I am getting this error:
Unable to register a client bearing no
175534 because there are no more
registration attempts. If you have
already registered with this server
then you must contact RIM to register
additional users.
Can anybody tell what is next step that I need to do?
The error message seems pretty clear on the next step:
.. you must contact RIM to register additional users.
The official response from blackberry support:
Hello,
Thank you for contacting BlackBerry Application Development Support.
This error means the keys have already been registered so cannot be registered again. To have this issue resolved a new set of signature keys will need to be issued and installed. Please note that signature keys are now completely free and issued several times a day, so the fastest way to get a new set would be to place a new order:
https://www.BlackBerry.com/SignedKeys
Prior to installing this new set of keys please first delete all present CSI files as well as the sigtool.* (DB, CSK, SET) files that will reside in the sub-directories of all development tools. Make sure to write down the PIN used to place the order as well, it will be needed when installing the keys.
After registering your keys and verifying that they are able to sign I would recommend backing them up some place safe in case anything should happen to your development environment:
http://supportforums.blackberry.com/t5/Testing-and-Deployment/Backup-and-Restore-BlackBerry-Code-Signing-Keys/ta-p/837925
Go to the first URL and request a new set of keys. You should get an order confirmation email right away. In about 1-2 hours you will get 3 more emails. Each one will have a CSI key attached. (The keys are free to generate)
To avoid this issue in the future, you can back up the keys, according to the instructions in the second link (above).
Good luck!