I store the token received from an API sign in process in the user's keychain. Then for all further requests to the API I get the token from the keychain to send to the API. This happens with each request made to the API. As I have understood the keychain is the right place to store sensitive information, so I'm not storing the token in the user defaults.
On iOS everything works as expected, but on macOS, there's an alert appearing that the App wants access to the keychain. The user can then select to allow it once or to allow it always. This has two major issues:
if the user chooses "once" the dialog will appear over and over again with each request the App does.
if the user chooses "always" the dialog will not appear for some time, but after a while it will reappear nevertheless.
Why is this behavior totally different between iOS and macOS? Or did I forgot to configure something?
From a security point of view, would it be okay to read the token once at the start of the app and store it in a property?
Although the Keychain on iOS and macOS share lots of similarities, there is one big difference between the two. iOS only has a single Keychain, whereas macOS can create any amount of Keychains. You can find more info on that here.
This means that we will have to tell the macOS Keychain to behave like the iOS Keychain, which we can via the kSecUseDataProtectionKeychain key, documented here. Setting this flag to true should solve your issue.
Related
I am requesting the user location in my app.
locationManager.requestAlwaysAuthorization()
This line of code should return this alert message:
However, I want the user to choose between "Don't Allow" and "Always Allow" only. how can I delete the "Only While Using The App" option?
Knowing that this is what I included in the info.plist, and deleting any row from these 3 rows in the info.plist is causing the app not to show this alert at all.
It is not optional anymore.
Since iOS 11 has been released, if your application requests the location to be always on (locationManager.requestAlwaysAuthorization()), the users will automatically be given all three options.
Unlike in previous iOS versions, all options have to be displayed to the user. That leads to: you have to add a key for both options.
Adapted from Apple's Article - Requesting Always Authorization:
You are required to include the NSLocationWhenInUseUsageDescription
and NSLocationAlwaysAndWhenInUseUsageDescription keys in your app's
Info.plist file. (If your app supports iOS 10 and earlier, the
NSLocationAlwaysUsageDescription key is also required.) If those keys
are not present, authorization requests fail immediately.
Reference: What's New in Location Technologies Video Session.
According to WWDC 2017 Session 713 about updates in Location technologies, you should always include When In Use description when linking against iOS 11 and later, if you want to request Always authorization. And iOS will additionally display an option to use location for When-In-Use mode.
Quote from session transcript.
So for iOS 11 we're asking all developers with Always requesting apps to additionally support the WhenInUse authorization mode. This change is both retroactive and forward-looking, so when the user updates to iOS 11, they will be able to authorize any app that requests Always authorization the WhenInUse authorization mode instead. If you link against the iOS 11 SDK, you must provide a WhenInUseUsageDescription. Otherwise, your app will be unable to request Always authorization. Furthermore, when your app requests Always authorization, we will additionally display an option to grant your app WhenInUse authorization instead. With these new three option prompts we have a new UsageDescription string as well. Your app needs to provide an AlwaysAndWhenInUse UsageDescription. Since this is a different key your app must provide it when you link against the new iOS 11 SDK. For apps linked against iOS 11 and later, Core Location will not use the old NSLocationAlways UsageDescription key.
When are not set you will catch a message in the debug console like:
The app's Info.plist must contain both NSLocationAlwaysAndWhenInUseUsageDescription and NSLocationWhenInUseUsageDescription keys with string values explaining to the user how the app uses this data
Open Info.plist as Source Code
And add the following xml chunk:
<key>NSLocationAlwaysUsageDescription</key>
<string>Location always usage description</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Location always and when in usage description</string>
<key>NSLocationUsageDescription</key>
<string>Location usage desription</string>
In my iPhone/iPad app's use case, there is a voting system and one device can send its vote once to the server. Therefore my server needs to identify user's device. I don't want the user to register an account because that makes the app complicate. However, I couldn't find a solution that works.
UDID is deprecated
I presume getting MAC address will get your app rejected by the app review process
I tried creating my own UUID using [[NSUUID UUID] UUIDString] and then storing it using NSUserDefaults, but the settings disappear if the user uninstalls the app
identifierForVendor is also reset when the user uninstalls the app
I considered advertisingIdentifier but because I'm not using it for advertisement, I presume it will also be rejected by the app review process
I'm not asking for a bulletproof solution in every situation. Just a solution that works even if the user uninstalls the app. Because I can generate my own UUID, I guess my question boils down to: How I can save data for the app that survives app uninstallation?
However if any of you have other approach, please feel free to inform me. Thanks.
Save the UUID into the keychain.
I developed an iPhone app. User need to log in to update their credentials. I'm using iOS Keychain feature to store the username and password. So, next time user launch the app user will be logged in. I would like to add remember me feature in my app. So, user will have an option to check the remember me or not.
My question is if the user don't want to remember his credentials, when I'm suppose to clear the keychain? How do I know if the app is closing/shutdown?
– applicationWillResignActive:
– applicationDidEnterBackground:
These two methods are called depending on the situation when the app enters background.(sleep button/phone call etc).
You can look it up in the docs.
https://developer.apple.com/library/IOs/#documentation/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UIApplicationDelegate
You meed to write the login credentials to application preferences.
(Here is how to read write to iPhone app preference)
http://knol.google.com/k/iphone-sdk-application-preferences#
Also here is how to read default preferences
http://www.redcodelabs.com/2009/07/read-iphone-preferences/
Here is my situation...
I want my password to be encrypted and at the same time I want it to be in iPhone settings (by adding resource and accessing it through NSUserDefaults), but i think NSUserDefaults saves the password or information in plane text and iPhone takes care of everything in its Settings app if there is any change or whatever.
How could I make sure that information that I see in the Settings is coming from and going back to Keychain but before that, Is it possible? If not any other way? May be writing encrypted file?
I DO NOT want settings to be in my app.
thank you
us
The Keychain service cannot be invoked from within Settings, you need to do this within your app. It is good practice to ask users for their password within your app in a login page or UIAlertView at least (like the App Store does).
From the user's point of view, they don't want to have to launch Settings, enter their password, and then launch your app to log in, they want to do it all in one place.
is it possible to get the user's information, such as apple ID, through the sdk? I am writing an app which will require an account linked to the app user. I want to allow the user to have one account across multiple devices, so using the device ID is not possible. The easiest way to do this, I am thinking, is to use the app user's apple ID as this account's ID, so not requiring them to create yet another account.
No, it's a privacy issue, just like their phone number.
They'd still have to create an account on your site since you don't have access to Apple's databases, and no one will be willing to give you their iTunes passwords for obvious reasons.
All you're really saving is them entering a user name, since they'd still have to give you a password. It's very easy to remember this data for future runs of your application. Look into using NSUserDefaults. I would recommend against using the UDID and give the user the option to save their password. That way if the phone is lost, whoever finds it doesn't have automatic access to the owner's account. If the user opts for automatic login, you can easily save the password and send it along with the username when the app loads.
It's not (AFAIK) possible. You can only retrieve the device's UDID.
What I've done in the past is link an account on my side with multiple UDIDs on the user's side, so when they install the app on various devices they can just use that single account and it will automatically link that device. Not ideal, but I've not seen a better solution.
If it is a game, you can use the Game Center Account to identify an user
Instead of the UDID for the device, you might try the [UIDevice currentDevice].identifierForVendor It is linked to the device and the app installation.
I am storing the username and encrypted password in a file that is stored in the user's application file space. When the app starts up, if it finds this file, it attempts a login without asking the user. Having a password, even encrypted, stored in the file system does seem insecure, but the application is not one where people are apt to try and steal passwords.