With APNS, when a device registers, how long is the token it registers with good for? The entire time the app is installed? I seem to recall a note in the documentation saying it was only good until sync/reset, but looking at the docs again I can't find that note (and it hasn't held true in my (admittedly non-extensive) testing). Can anyone confirm how long each token is valid for?
In addition to changing when a device is wiped clean, a token for a app/device combo will also change when being debugged on a device with Xcode vs. when that same app is run from a released (app store) version of the app.
I ran into issues recently when I was storing multiple device tokens for my own phone. I had two tokens in our database for one phone. One was assigned to me when I was developing with Xcode and the other was assigned from the released version of the app.
The problem was the debug token only worked on the sandbox servers and the release token only worked on the production servers. When I was testing, I was sending alerts to both tokens and Apple would drop my SSL connection because one of them was invalid.
That being said, I believe Apple reserves the right to change them whenever they want, which is why it's necessary to request the token on every application launch.
I hope that helps.
Looks like it only changes when a device is wiped. Found this in the documentation for application:didRegisterForRemoteNotificationsWithDeviceToken:
Note that the device token is
different from the uniqueIdentifier
property of UIDevice because, for
security and privacy reasons, it must
change when the device is wiped.
Related
I'm developing now an app for Apple TV. It is a client-server app. On registration, users get a free trial period. My goal is to avoid situations when user will just register new account or reinstall the app and get the trial period again. I need to identify if trial was already activated for each concrete device. So I would like to know if there is a legal or semi-legal way to identify each device? I will appreciate any ideas!
You can store some value in the Keychain (read more about it
here) and check if this value was previously stored in the Keychain. If so, it means that user installed your application before.
You can use identifierForVendor (documentation) but that changes once the app is uninstalled.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them.
Perhaps you could couple that with a user's email address to prevent creating new accounts. Not foolproof, but certainly makes it more difficult for the user to get around it. They would need to uninstall the app and use a different email address to circumvent you.
Is there any way to distribute an unsigned app through emails or internet?
I.e. itms-services://?action=download-manifest&url=URL_TO_PLIST.
Moreover, it is a security issue if it is possible to install unsigned app on a jailbroken device?
Thank you.
I can't quite understand what you're trying to do here - if you're trying to install an app that is not on the App Store and also unsigned with the itms-services-protocol, you are out of luck, as that is strictly for iTunes and App Store-links.
The only way to distribute an app that is not on the App Store, is with the ipa-file, but that has to be signed as well (at least for unjailbroken devices).
You can do it in cydia with link like cydia://package/[package name]
However security is really a question here. Not sure if there any code review for the accepted packages.
Sorry if this is an extremely late response, but the question isn't closed yet, so I'm assuming you still need an answer. It is a security concern, but with a jailbreak, users are technically "opening" their device to such security threats, so I don't think that's much of a concern. If they jailbreak, they probably know what they're doing.
To answer the first part of your question, you can use ldid to pseudo-sign the app and then create an itms-services:// link that users tap to install. The only caveat to this option is that the iOS Device will contact oscp.apple.com & ax.init.itunes.apple.com to verify the app's signature. If you want to bypass this, you'll have to change the DNS settings of the iOS device using a mobile configuration file. Do this using Apple's iPhone Configuration Utility, which will generate a .mobileconfig with your specified settings. You won't have to generate a specific file for each device, so you can make one and you're done.
Anyways, back to the topic, jailbreaking doesn't remove the need for codesigning, it only removes the need for an app to be signed with Apple's certificate(s). itms-services:// is a bypass (for developers) of the same "need". Since Apple obviously doesn't want people who aren't developers just signing apps that aren't approved by Apple and installing them, they've implemented certificate checks. The signing-certificate is cross-checked with Apple's two servers. One of the servers (I don't know which) checks for "iPhone Developer:" in the name of the certificate. The other checks that it was signed by Apple's WWDRCA Certificate. If the iOS Device gets a response from either of the servers signifying that the app is "bad". If the iOS Device doesn't get a response, it will still install the app.
The way to go with this in order to bypass would be to clone a DNS server, and create a specific entry that will change the IP of these two servers to something (anything) else. That way, the Device will not get a response, and will install the application.
modify the file SDKSettings.plist ： make code sign required value is NO
when build, selected project (not target) -- build setting -- code signning identity: Dont code sign
build, get the .ipa file can run on the jailbreak device
This is my first attempt to implement an anti-piracy code in my App.
I am using the Landon Fuller method (LC_ENCRYPTION_INFO).
This method is based on the App being encrypted when downloaded from the App store.
I checked and found out that downloaded Apps are indeed encrypted. I also found out that when I create my App in Xcode - even if I use Release build - the App is not encrypted yet.
Here's my question: When I upload the App to Apple using Application Loader, will they test it after it has been encrypted or will they test it in its unencrypted form? The latter will cause the App not to function properly, which will of course result in the App not being approved.
This article is old and thats the wrong way to deal with piracy. (using In-Apps you can verify purchase)
Most chances the app will be rejected because of using undocumented APIs,
the Author himself state he is not using it anymore.
quote from the page:
However, there's a problem -- none of this is documented by Apple. While most of the APIs and file formats are public, the actual distribution format is not. Apple could change the signature format, the meta-data plist, or any other distribution component at any time, at which point your copy protection may raise a false positive, and your paying customers will be wondering why you're wasting their time.
So the answer for your question is dont worry how they going to test it because it wont pass.
I am playing with idandersen's scifihifi-iphone code for keychain and came across the following behavior - I set the password using, say
[SFHFKeychainUtils storeUsername:#"User" andPassword:#"123"
forServiceName:#"TestService" updateExisting:YES error:&error];
Then delete test application from device and install it again - the previously set password appears to remain in keychain...
Is it the expected behavior? And is there a way to make sure that password I set will be deleted with the application?
Yes, this is the expected and correct behavior.
Some keychain items may be shared with other apps you control (that share the same keychain item access group).
You should just leave the info alone when your app is removed. You have no callback or method of removing the keychain items on deletion of your app.
Edit:
They finally reverted the behavior described in my answers, so until everybody move away from that range of versions, this should not happen anymore.
Unfortunately, this is not the case anymore. It has been changed since iOS 10.3.
This is an intentional change in iOS 10.3 to protect user privacy. Information that can identify a user should not be left on the device after the app that created it has been removed.
It has never been a part of the API contract that keychain items
created by an app would survive when the app is removed. This has
always been an implementation detail.
See the reference here.
I found this information on a blog which talks about invalid product ids.
http://troybrant.net/blog/2010/01/invalid-product-ids/
I tried everything suggested in the
Apple forums and here, and still
couldn’t get it to work. Found the
solution – your app needs to be
transferred by Xcode for the sandbox
to be enabled.
Obvious, right? Well, if you are
working with an update to an existing
account, the device will still treat
it as an App Store-installed app.
Delete it, then transfer it again. It should work now :)
i am also getting invalid product ids.i am not able to get clear in the above said point...
i am not able to understand what i need to do when transferring the application into device...
Kindly guide me out and thanks for your help
That point just means that you need to run the app from Xcode in order for the sandbox to be available. (Build and Run)
Invalid product ids are a major pain to debug. If you're sure you've gotten everything on that checklist, then you just need to wait. Then only other problem that I've seen is that you might need to remove the app from the device and redeploy in order to get good products back from the store.
I had trouble getting the app store to recognize my sandbox test account. I had to log out wit iTunes, sync, then log in again with iTunes. Just using the device itself to log in/out didn't help.